SEER-SEM

src: galorath.com

SEER for Software (SEER-SEM) is an algorithmic project management software application designed specifically to estimate, plan and monitor the effort and resources required for any type of software development and/or maintenance project. SEER, which comes from the noun, referring to one having the ability to foresee the future, relies on parametric algorithms, knowledge bases, simulation-based probability, and historical precedents to allow project managers, engineers, and cost analysts to accurately estimate a project's cost schedule, risk and effort before the project is started.

Video SEER-SEM

History

Predecessors

1966 System Development Corporation Model based on regressions.

1980 Don Reifer and Dan Galorath paper which prompted the building of the JPL Softcost model. This model, an early example of software estimation, allows for automated and performed risk analysis. Softcost was later made a commercial product by Reifer Consultants.

1984 Computer Economics JS-2 and Galorath Designed System-3 based on the Jensen model.

The Jensen-inspired System-3, and other modeling systems like Barry Boehm's COCOMO and early works by the Doty Associates can be seen as direct and indirect contributors to the software suite that would be developed by Galorath in the late 1980s.

Version 1.0

In 1988, Galorath Incorporated began work on the initial version of SEER-SEM which resulted in an initial solution of 22,000 lines of code. SEER-SEM version 1.0 was released on 13 5.25" floppy disks and was an early product running on Windows version 2. Designing SEER-SEM for Windows was considered risky as the operating system had yet to establish itself as a viable competitor to the current dominant OS, Microsoft's MS-DOS. However, the adoption of a Windows-based format proved to be worthwhile, allowing SEER-SEM to offer a much more intuitive user interface than would have otherwise been available in MS-DOS. Galorath chose Windows due to the ability to provide a more graphical user environment, allowing more robust management tradeoffs and understanding of what drives software projects.

Next Versions

Since that initial release in 1988, SEER-SEM has undergone numerous upgrades, keeping up with changing technology, adapting to better meet the needs of the customer, and altering the model to achieve more precise estimates. For example, the 1994 release of SEER-SEM version 4 included major enhancements to the core math behind the model, handling the realities of projects rather than just a Rayleigh curve approximation, as well as dozens more knowledge bases and the latest research in software science and complexity metrics. 2003 saw SEER-SEM add significant new features such as Goal Setting and Risk Tuning. Both features operated as their names suggest with Risk Analysis allowing project managers to make changes to estimates and Goal Setting allowing for projects to not only be estimated, but also to be managed. Version 6 of SEER for Software was the first to be fully COM-enabled, allowing SEER to both input and output through various Microsoft products, such as Excel. Version 7 included better handling of projects that stretch beyond their optimal effort.

Current Version

SEER for Software Version 7.3 is a vast improvement over the original implementation, representing perhaps the first time that any version of SEER could be integrated to support all phases of a project's lifecycle. The size of the software has grown to over 200,000 source lines of code and shifted from simply a means to generate work estimates through parametric modeling to a system that buttresses those results with simulation-based probability and over 20,000 historical cases to draw conclusions from.

The original SEER-SEM has also branched into:

• SEER for Information Technology - SEER-IT - a version of SEER created to aid IT professionals estimate the design, build, and maintenance of information technology infrastructures and service management projects.
• SEER for Hardware, Electronics, & Systems - SEER-H - a version of SEER designed to aid in the life-cycle cost estimation of any type of hardware, electronics or system.
• SEER for Manufacturing - SEER-MFG - a version of SEER tailored for estimating the detailed production costs of manufacture, covering a wide range of state-of-practice and state-of-the-art manufacturing process knowledge.

Maps SEER-SEM

Users

SEER for Software has thousands of licensed users including aerospace giants, banking, finance, retail, insurance, and manufacturing. Users include Bank of America, Boeing, Ford Motor Company, Lockheed Martin, National Oceanic and Atmospheric Administration, Northrop Grumman, Siemens, Raytheon, and the US Department of Defense.

src: www.seerinteractive.com

Technical details

SEER for Software is designed to be run inside of a Windows environment, and from version 6 onwards, is fully COM-enabled, allowing users to have SEER interact with many Windows products including Microsoft Office. Its current primary API relies on Microsoft Automation. The program itself is written in C and C++.

src: www.phaedsys.com

Group 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?

src: www.seerinteractive.com

Software Sizing

Software size is a key input to any estimating model and across most software parametric models. Supported sizing metrics include source lines of code (SLOC), function points, function-based sizing (FBS) and a range of other measures. They are translated for internal use into effective size (${\displaystyle S_{e}}$). ${\displaystyle S_{e}}$ is a form of common currency within the model and enables new, reused, and even commercial off-the-shelf code to be mixed for an integrated analysis of the software development process. The generic calculation for ${\displaystyle S_{e}}$ is:

${\displaystyle S_{e}=NewSize+ExistingSize*(0.4*Redesign+0.25*Reimpl+0.35*Retest)}$

As indicated, ${\displaystyle S_{e}}$ increases in direct proportion to the amount of new software being developed. ${\displaystyle S_{e}}$ increases by a lesser amount as preexisting code is reused in a project. The extent of this increase is governed by the amount of rework (redesign, re-implementation, and retest) required to reuse the code.

src: i.ytimg.com

Function-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 ${\displaystyle S_{e}}$, 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 ${\displaystyle S_{e}}$. After FBS is translated into function points, it is then converted into ${\displaystyle S_{e}}$ as:

${\displaystyle S_{e}=Lx*(AdjFactor*UFP)^{\frac {Entropy}{1.2}}}$

where,

• ${\displaystyle Lx}$ is a language-dependent expansion factor.
• ${\displaystyle AdjFactor}$ 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.

src: www.admcrystals.com.au

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:

${\displaystyle K=D^{0.4}*({\frac {S_{e}}{C_{te}}})^{E}}$

where,

• ${\displaystyle S_{e}}$ is effective size - introduced earlier
• ${\displaystyle C_{te}}$ 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
• ${\displaystyle D}$ is staffing complexity - a rating of the project's inherent difficulty in terms of the rate at which staff are added to a project.
• ${\displaystyle E}$ 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:

${\displaystyle t_{d}=D^{-0.2}*({\frac {S_{e}}{C_{te}}})^{0.4}}$

The duration equation is derived from key formulaic relationships. Its ${\displaystyle 0.4}$ 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.

src: i.ytimg.com

Notes

src: www.seerinteractive.com

References

Fischman, Lee; McRitchie,Karen; and Galorath, Daniel D. Inside SEER-SEM, CROSSTALK The Journal of Defense Software Engineering, April 2005, pp. 26-28.

SEER-SEM Official Site

Source of the article : Wikipedia