An Analysis of Hybrid Tool Estimator: An Integration of Risk with Software Estimation

,


INTRODUCTION
There are two main dimensions in project metrics. The first dimension main concentrates on the development schedule so that we can avoid delay and potential problems and risks. The second dimension main focuses on the quality of the software so that the developed software is of good quality and it satisfies the customer. So, most of the organizations focuses on the above said two dimensions. There are many effort estimation techniques for software systems developments are available (Vijay and Manoharan, 2009;2010). But none of the models paid attention to schedule and quality parameters. So, we have developed a new hybrid estimation technique which is fully focussed on assuring the quality in effort estimation for software system development. In this study, we have created a new hybrid model which estimates the effort, schedule and quality parameters. The entire results of the developed hybrid model have been illustrated in the results section. An example software system used to apply the proposed study is the testing software. In the results comparisons section, the effort (in terms of person-months) is used to compare the various results of some available models with the proposed result. In the conclusion section, the results between proposed and existing scenario are compared with the detailed graphs and performance chart.

MATERIALS AND METHODS
Function points: Function-oriented software metrics is used to measure the functionality delivered by the application as a normalization value. The most widely used function-oriented metric is Function Point (FP). The traditional Functional Point metric method does not take into account the quality parameters of the software and moreover the values that been assigned to the parameters will be decided by the project managers experience. So, the values for the parameters will vary depending upon the manager's interest on the project. As a net result, it is very difficult to estimate the software by these varying parameters. So, we can't use this value for estimating, the schedule, effort needed, project time, cost estimation etc. So, we have made a vast literature survey by means of questionnaire to various software companies. The questionnaires were given only to the project managers who are familiar in their projects. From their ideas and suggestions, we have derived the parameter values and by using those values the effort will be calculated automatically. This effort estimated value also covers some of the important quality parameter values. So, we have also made a comparative analysis of the existing functional point model with the developed model which covers the quality aspects of the software. The detailed output of the derived model is shown below in the form of snapshots.

Analysis of the model:
In this derived hybrid model, the effort estimation for particular software has been calculated by using the following methods:  By using the results that we got by using the above said model, we have made a comparative study in the form of a graph. The output of the result is given below.
Integration of software risk with estimation: Once the effort has been found by using one of the above said estimation methods. The User can select the method needed for estimating the software manually using menudriven option from the tool. Once the effort has been found, then the result has to be integrated with risk.
Software risk assessment: Large software projects have a very high frequency of schedule overruns, cost overruns, quality problems, and outright cancellations. Although software cost estimating is a very difficult intellectual problem, there are three fundamental equations that are linked together for estimation. They are given below: Size of deliverable/assignment scope = staff Size of deliverable/production rate = effort Effort/staff = schedule

Functions of hybrid tool:
Step 1: Sizing specifications, source code, and test cases: The first step in any software estimate is to predict the sizes of the deliverables that must be constructed. Sizing must include all deliverable such as specifications, documents, and test cases as well as source code. As of 2008, sizing is a standard feature of commercial software cost estimating tools, and a variety of sizing methods are now included, such as: • Sizing based on function point metrics • Sizing based on Lines Of Code (LOC) metrics It should be noted that one very common risk with estimates based on "lines of code" metrics is that such estimates are not reliable for predicting user documents or any non-coding activity such as quality assurance, data base administration, and project management. LOCbased estimates and function point-based estimates are of approximately equal accuracy for predicting coding activities but the LOC estimates usually are less accurate for non-code activities. Since studystudy in all of its forms is often the most expensive task for large defence applications, this problem is fairly significant.
Step 2: Estimating defects and defect removal efficiency levels: A key aspect of software cost estimating is predicting the time and effort that will be needed for design reviews, code inspections, and all forms of testing. In order to estimate defect removal costs and schedules, it is necessary to know about how many defects are likely to be encountered. Poor quality control is another major risk that can lead to litigation. Lack of early defect detection and removal via inspections can lead to huge delays in testing schedules. What happens is that testing might start on time, but due to the unexpected volume of defects it cannot end on time. Testing is the primary phase where schedules begin to go out of control. The defect removal efficiency of each step will also be estimated. The effort and costs for preparation, execution, and defect repairs associated with each removal activity will also be estimated.
Step 3: Selecting project activities: Once the size of various deliverables has been approximated the next step is to determine which specific activities will be carried out for the project being estimated. This is one of the major areas where software cost estimating tools excel. Activity-based cost estimates with perhaps 20-25 activities are the level of precision offered by modern cost estimating tools.
Step 4: Estimating staffing levels: Although staffing, effort, costs, and schedules are all important for the final estimate, the normal place to start estimating is with staffing levels. The fundamental equation for determining staff is: Size of deliverable/assignment scope = staff The UCP tool applies this fundamental staffing equation in a wide variety of forms, including but not limited to: Pages of specifications / assignment scope = analysts Lines of source code/assignment scope = programmers Test cases/assignment scope = testers Pages of user manuals/assignment scope = technical writers Number of employees / assignment scope = managers Step 5: Estimating software effort: The term "effort" defines the amount of human study associated with a project. The amount of effort can be expressed in any desired metric, such as study hours, study days, study weeks, study months, or study years. The general algorithm for predicting effort is: Size of deliverable / production rate = staff effort Here too this basic equation is used in a variety of forms including but not limited to: Pages of specifications / production rate = analyst months Lines of source code / production rate = programmer months Test cases/production rate = testing months Defects found/production rate = restudy months Pages of user manuals/production rate = writing months Step 6: Estimating software costs: The fundamental equation for estimating the cost of a software activity is simple in concept, but very tricky in real life: Effort * (salary + burden) = cost Step 7: Estimating software schedules: The fundamental equation for estimating the schedule of any given software development activity is: Effort / staff = time period Step 8: Estimating requirements changes during development: One important aspect of estimating is dealing with the rate at which requirements "creep" and hence makes projects grow larger during development. Fortunately, function point metrics allow direct measurement of the rate at which this phenomenon occurs, since both the original requirements and changed requirements will have function point counts.
Step 9: Software risk analysis: The software industry has long been troubled by major schedule slippage, major cost overruns, and a high incidence of outright failure. Of all the troublesome factors associated with software, schedule slips stand out as being the most frequent source of litigation between out sources vendors and their clients. Schedule slips are also the main reason for executive frustration with software for internal projects.

RESULTS AND DISCUSSION
The existing results for the Tested application in the software industry are given below: • Based on the automated hybrid model (Fig. 11

CONCLUSION
Based on the above results, the proposed 64 person-months of effort is nearer value to the average result of other estimation models. And hence this type of estimation may be recommended for the software development. The unique difference between the proposed and existing estimation of effort for the software system development is the level of quality consideration. That is, existing estimations are using only few quality factors for effort estimation, but the proposed effort estimation covers the important quality factors, which automatically reflects in the development of software. Other metrics may be used to estimate the effort and substituting other quality factors can be explored as a future scope.