History
1966 System Development Corporation Model based on regressions. 1980 Don Reifer andGroup of Models
SEER for Software (SEER-SEM) is composed of a group of models working together to provide estimates of effort, duration, staffing, and defects. These models can be briefly described by the questions they answer: * Sizing. How large is the software project being estimated (Lines of Code, Function Points, Use Cases, etc.) * Technology. What is the possible productivity of the developers (capabilities, tools, practices, etc.) * Effort and Schedule Calculation. What amount of effort and time are required to complete the project? * Constrained Effort/Schedule Calculation. How does the expected project outcome change when schedule and staffing constraints are applied? * Activity and Labor Allocation. How should activities and labor be allocated into the estimate? * Cost Calculation. Given expected effort, duration, and the labor allocation, how much will the project cost? * Defect Calculation. Given product type, project duration, and other information, what is the expected, objective quality of the delivered software? * Maintenance Effort Calculation. How much effort will be required to adequately maintain and upgrade a fielded software system? * Progress. How is the project progressing and where will it end up. Also how to replan. * Validity. Is this development achievable based on the technology involved?Software Sizing
Software size is a key input to any estimating model and across mostFunction-Based Sizing
While SLOC is an accepted way of measuring the absolute size of code from the developer's perspective, metrics such as function points capture software size functionally from the user's perspective. The function-based sizing (FBS) metric extends function points so that hidden parts of software such as complex algorithms can be sized more readily. FBS is translated directly into unadjusted function points (UFP). In SEER-SEM, all size metrics are translated to , including those entered using FBS. This is not a simple conversion, i.e., not a language-driven adjustment as is done with the much-derided backfiring method. Rather, the model incorporates factors, including phase at estimate, operating environment, application type, and application complexity. All these considerations significantly affect the mapping between functional size and . After FBS is translated into function points, it is then converted into as: : where, * is a language-dependent expansion factor. * is the outcome of calculations involving other factors mentioned above. Entropy ranges from 1.04 to 1.2 depending on the type of software being developed.Effort and Duration Calculations
A project's effort and duration are interrelated, as is reflected in their calculation within the model. Effort drives duration, notwithstanding productivity-related feedback between duration constraints and effort. The basic effort equation is: : where, * is effective size - introduced earlier * is effective technology - a composite metric that captures factors relating to the efficiency or productivity with which development can be carried out. An extensive set of people, process, and product parameters feed into the effective technology rating. A higher rating means that development will be more productive * is staffing complexity - a rating of the project's inherent difficulty in terms of the rate at which staff are added to a project. * is the entropy - In days gone by entropy was fixed at 1.2. Next it evolved to 1.04 to 1.2 depending on project attributes with smaller IT oriented projects tending toward the lower. Currently entropy is observed as 1.0 to 1.2 depending on project attributes. SEER will allow an entropy less than 1.0 if such a circumstance is observed as well. Once effort is obtained, duration is solved using the following equation: : The duration equation is derived from key formulaic relationships. Its exponent indicates that as a project's size increases, duration also increases, though less than proportionally. This size-duration relationship is also used in component-level scheduling algorithms with task overlaps computed to fall within total estimated project duration.References
External links