* the tool must provide for scheduling the project
* the schedule must be derived from the estimated effort
* the tool must automate schedule generation to the extent feasible
* the tool must allow for human intervention when creating the schedule
* the generated schedule must have adequate detail and must be exportable to a familiar intermediate program such as MS-Excel
* the tool must be based on estimated PD, but allow for scheduled PD to be different from the estimated PD
This eleventh criterion is so because when we honestly estimate the effort in PD and then schedule it, the scheduled PD overshoots the estimated PD due to loss of time in personnel allocation, fragmentation of work, idle time, and start-to-finish relationships.
Estimation for Part Life Cycle Projects
Significant projects, such as software maintenance, enterprise resource planning (ERP) implementation, and testing projects, are not full software development life cycle (SDLC) projects. The software estimation tool has to cater to these projects too, using such techniques as task-based estimation. Task-based estimation is parameterized so that different project types can be defined and used by the organization.
Therefore, the twelfth criterion for selecting a software estimation tool is
All software should be built with users in mind. An expert can work with any tool, but the main distinguishing characteristic of a good software estimation tool is that it can produce an expert-quality output even from a person of average expertise. This distinction can be achieved by building a tool with an intuitive interface that keeps the need for training on how to use the tool to a minimum. This is possible with the availability of GUI tools. It is also possible to use the wrong controls, which places a strain on the user instead of making usage of the tool easier. Oftentimes, software tools are developed with a focus on making the user interfaces more appealing rather than on being functional, making the tool more complex to use. The tool must be geared more toward functionality and usability than to jazziness. A simple user interface (UI) is always the better UI.
Therefore, the thirteenth criterion for selecting a software estimation tool is
* the tool must be built with usability in mind, and with an intuitive interface that makes it easier for a person with average skills to quickly master the tool
Usage of Popular Software Sizing Techniques
Software estimation is perhaps as old as software development itself. Some estimation techniques have become popular and are used by many organizations. Especially common are the LOC, function point analysis (FPA), and UCP techniques. Two other widely used techniques are object points and feature points.
Therefore, the fourteenth criterion for selecting a software estimation tool is
* the tool must provide for as many commonly used software estimation techniques possible
Auditability
"Two heads are better than one" is a well-known dictum, and it forms the basis of software inspections, reviews, and walkthroughs. Therefore, it is unnecessary to say that the estimate made by one person, however diligent and expert that person may be, needs to be reviewed by one more peer. The software estimation tool must provide for making a detailed estimate so that this estimate can be reviewed and improved upon. This detailed estimate also assists in reconciling with actual effort spent on the project in order to draw lessons from the experience, and improve the process of estimation in subsequent projects.
Therefore, the fifteenth criterion for selecting a software estimation tool is
* The tool must provide for making estimates that are auditable
Reporting Capability
The result obtained by estimating is to be submitted to the client, management, or user. These reports should not include the unnecessary details, but present only the details that are required.
Therefore, the sixteenth criterion for selecting a software estimation tool is
* the tool should generate a summary report and a detailed report for every estimate made, as well as a summary report of all estimation's made on the tool
Estimator Productivity
It is extremely important to keep in mind the pressure that the estimators, who are usually either project leaders or project managers, are under. The software estimation tool must facilitate picking data from a predefined list as much as possible so that estimators are not required to type the data inputs into the tool. It is also likely that projects in an organization are similar in nature, though certainly not identical. Therefore, the tool must also enable the ability to copy an existing estimate and to modify it to generate a new estimate. This saves a great deal of the estimator's time and therefore money for the organization.
Therefore, the final two criteria (seventeenth and eighteenth) for selecting a software estimation tool are
* the tool must provide for selection from a list of choices as much as possible
* the tool must allow the "copy, modify, and generate" process for a new estimate
* the schedule must be derived from the estimated effort
* the tool must automate schedule generation to the extent feasible
* the tool must allow for human intervention when creating the schedule
* the generated schedule must have adequate detail and must be exportable to a familiar intermediate program such as MS-Excel
* the tool must be based on estimated PD, but allow for scheduled PD to be different from the estimated PD
This eleventh criterion is so because when we honestly estimate the effort in PD and then schedule it, the scheduled PD overshoots the estimated PD due to loss of time in personnel allocation, fragmentation of work, idle time, and start-to-finish relationships.
Estimation for Part Life Cycle Projects
Significant projects, such as software maintenance, enterprise resource planning (ERP) implementation, and testing projects, are not full software development life cycle (SDLC) projects. The software estimation tool has to cater to these projects too, using such techniques as task-based estimation. Task-based estimation is parameterized so that different project types can be defined and used by the organization.
Therefore, the twelfth criterion for selecting a software estimation tool is
All software should be built with users in mind. An expert can work with any tool, but the main distinguishing characteristic of a good software estimation tool is that it can produce an expert-quality output even from a person of average expertise. This distinction can be achieved by building a tool with an intuitive interface that keeps the need for training on how to use the tool to a minimum. This is possible with the availability of GUI tools. It is also possible to use the wrong controls, which places a strain on the user instead of making usage of the tool easier. Oftentimes, software tools are developed with a focus on making the user interfaces more appealing rather than on being functional, making the tool more complex to use. The tool must be geared more toward functionality and usability than to jazziness. A simple user interface (UI) is always the better UI.
Therefore, the thirteenth criterion for selecting a software estimation tool is
* the tool must be built with usability in mind, and with an intuitive interface that makes it easier for a person with average skills to quickly master the tool
Usage of Popular Software Sizing Techniques
Software estimation is perhaps as old as software development itself. Some estimation techniques have become popular and are used by many organizations. Especially common are the LOC, function point analysis (FPA), and UCP techniques. Two other widely used techniques are object points and feature points.
Therefore, the fourteenth criterion for selecting a software estimation tool is
* the tool must provide for as many commonly used software estimation techniques possible
Auditability
"Two heads are better than one" is a well-known dictum, and it forms the basis of software inspections, reviews, and walkthroughs. Therefore, it is unnecessary to say that the estimate made by one person, however diligent and expert that person may be, needs to be reviewed by one more peer. The software estimation tool must provide for making a detailed estimate so that this estimate can be reviewed and improved upon. This detailed estimate also assists in reconciling with actual effort spent on the project in order to draw lessons from the experience, and improve the process of estimation in subsequent projects.
Therefore, the fifteenth criterion for selecting a software estimation tool is
* The tool must provide for making estimates that are auditable
Reporting Capability
The result obtained by estimating is to be submitted to the client, management, or user. These reports should not include the unnecessary details, but present only the details that are required.
Therefore, the sixteenth criterion for selecting a software estimation tool is
* the tool should generate a summary report and a detailed report for every estimate made, as well as a summary report of all estimation's made on the tool
Estimator Productivity
It is extremely important to keep in mind the pressure that the estimators, who are usually either project leaders or project managers, are under. The software estimation tool must facilitate picking data from a predefined list as much as possible so that estimators are not required to type the data inputs into the tool. It is also likely that projects in an organization are similar in nature, though certainly not identical. Therefore, the tool must also enable the ability to copy an existing estimate and to modify it to generate a new estimate. This saves a great deal of the estimator's time and therefore money for the organization.
Therefore, the final two criteria (seventeenth and eighteenth) for selecting a software estimation tool are
* the tool must provide for selection from a list of choices as much as possible
* the tool must allow the "copy, modify, and generate" process for a new estimate
No comments:
Post a Comment