Project Estimating Software

Agile software development practices are predicated on the following tenets as introduced in 2001 in the Agile Manifesto [1]

•  Individuals and interactions over processes and tools
•  Working software over comprehensive documentation
•  Customer collaboration over contract negotiation
•  Responding to change over following a plan

Agile development processes rely on experienced, highly skilled people communicating with clients and each other to deliver software that provides the clients with the most value for the money they spend.  This requires both developers and consumers of software to accept the reality that things will change over the course of the project and that the software that is eventually delivered may not be the same as that was envisioned when the project was first kicked off.

At any given time, the agile software development team is only working on the feature that the customer currently feels is the most valuable.  Estimation is performed by the team (including developers, BAs, QAs and customer representatives) and is only focused on the feature that is currently on deck.  At the end of an iteration, the customer has an opportunity to review the implementation to date and can reprioritize remaining features based on changes in their requirements, market or expectations.  So estimating beyond the current feature doesn’t really make agile sense.

Unfortunately, the fact that estimation doesn’t make sense for the agile team does not mean it doesn’t make sense for the business.  The business needs to see the forest not just the trees.  Customers need an idea when their software will be delivered, businesses need to prep the market for new products and features, businesses need to be able to optimize resource allocations across many projects, etc.   This of course begs the question of how to perform an estimate for software when you really don’t know exactly what software you’re going to build.  As an industry, we’ve been pretty unsuccessful estimating software projects even when we think we have a handle on the end product – how can we be successful with so much uncertainty.

First we accept uncertainty and commit to incorporating uncertainty into our estimates.  Once we’ve made that commitment we are then free to pursue one of many top level estimating techniques to help us get our head around a likely range of values for cost and schedule based on what we currently know about the software project.  Parametric techniques are particularly suitable for this task especially for an organization that has some historical data from previous agile projects.  Parametric estimating models like TruePlanning for Software provide a repeatable framework through which an organization can study their past performances on similar projects (similar number of features, similar market, similar customer, etc) and use what they learn to perform estimates on the project at hand.   The amount and nature of the similarities should guide the amount of uncertainty in the estimate.  Organizational history can be used to map Story Points or User Stories to a size measurement such as source lines of code, function points or user points.  Analysis of performance on past projects can inform decisions about productivity and other project drivers.  This information can be used to drive the parametric algorithms to develop estimates for cost, effort and schedule.

Since we have already acknowledged that we didn’t get the question right, it’s unreasonable to assume that the answer will be ‘the right answer’.  What we do come away with is a range for cost, effort and schedule which will give decision makers realistic data to work with. If we have properly studied our history and thoughtfully assessed uncertainty, we can present these ranges with a quantifiable degree of certainty. 

What process does your organization employ to plan around agile induced uncertainties?

[1] Agile Alliance, “Agile Software Development Manifesto”, Feb 2001, available at www.agilemanifesto.org (retrieved January 2010)

This FREE workshop features government and industry speakers discussing how the current fiscal environment impacts the day-to-day estimating challenges faced by government program offices and their commercial counterparts.  These events seek to bring leaders together to share ideas and experiences about their most pressing issues.

We are looking to professionals, such as you to contribute ideas and best practices.  For more information or to register:http://www.pricesystems.com/services/predictive_modeling_schedule.asp

“I think we have an obligation to work with industry to ensure that our suppliers do not just remain world class in defence, but aspire to be world-class manufactures that can withstand comparison to other industries.”

Chief of Defence Procurement, Sir Robert Walmsley

Is this a practical proposition or is it a pipe dream?  The following excerpt from Dale Shermon’s Systems Cost Engineering attempts to make the case that this type of comparison is possible.


Many of the statements in proposals and marketing literature stating the superiority of a company are anecdotal or at best qualitative evidence. It has not been possible to quantify the productivity of industry to demonstrate that one manufacturer is more efficient than another.

In the ship building industry it is possible to benchmark commercial ship yards using a metric called Compensated Gross Tonnage (CGT). CGT measures the complexity of building a ship. It is calculated by multiplying the gross tonnage by the relevant CGT coefficient (calculated by the Organisation for Economic and Commercial Development [OECD]).  However, this is only applicable to this one industry. Other metrics exist in other industries, but what is really required is a single benchmarking technique and measure.

Benchmarking with Cost Normalization.  Forty years ago, PRICE Systems developed a metric that can be used to normalize cost and support the benchmarking practices needed to reach Sir Walmsley vision.  Manufacturing Complexity represents the normalized cost density of an item that has been manufactured. It has two dimensions: technology and productivity. Hence, more than one Manufacturing Complexity can exist. As aircraft are made using different technologies and by different companies, these have various complexity figures. However, if the technology is constant, the only dimension that changes is productivity. As a result, it is possible to compare the efficiency of companies that produce similar technologies.

Supplier Assessment.  One obvious and practical application of this technique is Supplier Assessment. This technique exploits the capability of parametric models to compare organization’s normalized cost density or Manufacturing Complexity. If, on paper, you have very similar proposals, how can you judge which organization will provide the best value for money? Heritage data will determine the level of development that is required and Operating and Support Cost will establish the Through Life Cost, but if these cannot differentiate the proposals perhaps the productivity of the companies should be considered. This is not a simple comparison, but with manufacturing complexity this can be achieved easily.

This process will lead to your suppliers knowing that you are able to control them; they will need more control on themselves. It will enable you to perfect your negotiation skill, leading to more success, as better negotiation material is utilised based on technology cost drivers. A parametric questionnaire is a possible tool to enable proposal validation in minutes.  All this information can be garnered at a very early stage in a project if required, providing better estimating accuracy for the purchased items. Normalization enables a bigger data sample as previous proposals received from the same companies can be compared. This in turn enables the establishing of trends. Are the suppliers becoming more or less efficient? Ultimately, these comparisons can be used to determine preferred suppliers.

Conclusion.  This method of benchmarking a project or company can be used for all environments. With the ability to move across environments it is possible to compare commercial and military organisations equally. Decisions and judgments can be made between Commercial and Military suppliers where no military competition exists.  It is possible to assess the productivity of an organisation or country at System, sub-system and equipment levels. The technique can be used to compare the whole cost or just the labour cost if that is the focus of your efficiency drive.

It is possible to determine preferred suppliers on a justified basis, or alternatively it is possible to demonstrate the efficiency of your organisation when the customer is skeptical about your productivity or your drive to improve productivity.

Finally, many organisations already have a license to use the PRICE models and over 8,000 people worldwide have been trained and are familiar with the PRICE methodology. This is not a new idea, PRICE has been established since 1975, but this new application of an established technique can help decision maker take the right decision regarding source selection cross industry and national companies. Alternatively, it can enable industry to demonstrate, with proof, that they are more effective than other solutions.

I’m not a golfer. But we’ve all heard one say “that’s why I play” after hitting a shot and feeling like it all came together. What “it” is, in terms of mechanics and timing, I’m not really sure. 

In our own world of parametrics, it’s the feeling of adding value in that golden moment of facilitating decisions and forward momentum. We wear many hats: estimating, consulting, systems engineering...even cost accounting.  Building an AoA, ICE or ROM is where rubber-meets-the-road in regards to configurations and assumptions. 

Not too long ago I was in a discussion with a number of Subject Matter Experts and realized that most of us at the table hadn’t had a chance to hear each other’s perspectives. Enter the consensus-maker! With parameter pick-lists and definitions displayed as talking points, we talked through the scenarios and operational expectations. 

We clearly needed a common frame of reference to get to a real-time resolution. The group built momentum, carrying over past the meeting. My role that day was to facilitate. When it all comes together, bridging between representatives from business operations, program management, systems engineering and field operations, it’s a very good feeling to add value. Maybe not as perfect as a hole-in-one, but I’ll take “it” every time!

1. A round table peer review, where we describe and defend our parametric modeling approach as well as consistency across similar objects/ systems/ alternatives. 
2. Introduction of an independent 3^rd party, not part of the estimating team, who is an experienced modeler. This resource can take the client perspective in reviewing, say, procurement versus cost-of-ownership as well as comparables from similar program experiences.  
3. Take an agile approach where your project leader is the “product owner” who reviews all interim deliverables top-down.  
4. Another option is incorporating a client representative into your pre-release reviews for similar validation testing. 
5. Finally, we pair off internally to verifying each other’s work against the real-time documentation we keep per common templates.  (Available from PRICE Systems, for both hardware and software modeling inputs). They are great visualization tools for internal parameter-tracking, plus external pre/ post model review with customers.

...wear the worst shoes. The cobbler was a master at his craft; he was just too tired to practice it when he got home from the shop.  Sound familiar?

A disciplined approach to understanding (functional) requirements as well as analogous projects (with actuals) is our not-so-secret sauce. Why run the risk of creeping back up our career learning curve? There’s already enough scope creep to keep us busy. Plus, for you management types charged with prospecting, a consistent approach towards estimation is a great way to connect with people who've felt the pain of being the cobbler's kids.

I recently reconnected with a colleague who found himself immersed in an early-stage, large-scale federal software project. Discussion points ranged from parametrics utility to sizing to Earned Value Management. Not leaving my toolset at the shop translated into good conversation with followup request. A bad example is yours truly, a year ago, so immersed in a highly-featured personal project, that he neglected to find agreement on scope and cost with his team. Bad idea! Now my “shoes” (a one-off custom hot-rod) are way behind schedule and way over budget. Keeping on my professional cost estimation consulting hat would have saved on both… bigtime! 

What follows is PRICE's interpretation of the DOD-HDBK-343, which addresses design, construction and testing requirements for a type of space equipment. Within the document are specified several levels of Class Definitions for space programs, space vehicles and space experiments. The classes are briefly described below.

• Class A - High Priority, Minimun Risk
• Class B - Risk with Cost Compromises
• Economically Re-flyable or Repeatable
• Minimum Acquisition Cost

HDBK-343, originally published in 1986, was reviewed and found to be still valid in 1992.  We can't due justice to the 79-page document in a blog, but we can give you a brief description of each class and PRICE's interpretation of the platform for those classes.
 

The PRICE Platform alters the cost estimating relationships (particularly in the development phase) between the groups of hours and cost within the model, and is used to describe the operating specification of the item being costed. For example, as the platform is increased, the amount of design hours (thus cost) changes to a higher proportion of the development cost. This reflects the extra specifications and tests needed to qualify the design for a given operating specification.  Electronic and structural complexities are also linked platform.  Thus, when considering the platform for a specific HDBK-343 Class, the estimator must also choose appropriate complexities.

Class and Platform Descriptions

• Class A:  Defined as high-priority, minimum risk effort. Characteristics usually involve some combination of: high national prestige, long Life, high complexity, high use of redundancy, soft failure modes, independent qualification items, complete flight spares, highest cost, and a critical launch time.  This class is considered to use a Platform of 2.0 for UNMANNED equipment; 2.5 for MANNED equipment.  NOTE:  It is possible that this Platform may have a higher value IF a number of conditions force higher quality components, longer testing, and other conditions above the HDBK-343 descriptions for this class.
• Class B:  Defined as a risk with cost compromises effort.  It is a high priority, medium-risk, with cost saving compromises made primarily in areas other than design and construction.  Characteristics usually involve a combination of: high national prestige, medium life, high complexity, soft failure modes, protoflight qualification, limited flight spares, limited use of redundancy, high cost, short schedule, and a critical launch time.         This class is considered to use a Platform of 1.9.  NOTE:   It is possible that this Platform may have a higher (or lower) value IF a number of conditions force different quality components, different testing, and other conditions varying the HDBK-343 descriptions for this class.
• Class C:  Defined as economically re-flyable or repeatable.  It is a medium or higher risk effort, that is economically re-flyable or repeatable.  Characteristics usually involve a combination of: medium to high national prestige, short life, low to medium complexity, small size, single string designs, hard failure modes, very limited flight spares, medium cost, short schedule, and a non-critical launch time.  This class is considered to use a Platform of 1.8.  NOTE:  It is possible that this Platform may have a higher (or lower) value IF a number of conditions force different quality components, different testing, and other conditions varying the HDBK-343 descriptions for this class.
• Class D:  Defined as a higher risk, minimum cost effort.  Characteristics usually involve a combination of: medium to low national prestige, short life, low complexity, small size, single string designs, simple interfaces, hard failure modes, and a non-critical launch time.    This class is considered to use a Platform of 1.7.  NOTE:  It is possible that this Platform may have a higher (or lower) value IF a number of conditions force different quality components, different testing, and other conditions varying the HDBK-343 descriptions for this class.

 If you need help with this or other aspects of parametric modeling, post a comment or reach out to our subject matter experts through help@pricesystems.com

PRICE Systems recently accepted an assignment to complete a "Should Cost" estimate for a U.S. ally on a weapon system. The estimate included not only analysis on production costs, but also should cost on various operations and support costs. The only information provided by the client was quantity and time frame for production. A major ground rule for the estimate was that all data specific to the weapon system must come from publicly available information.  For example, mass, manufacturing process, and learning curve information must come from the public domain. 

After reviewing the scope for the estimate, we decided to also collect data on four similar weapon systems. This would allow us to provide not only a “Should Cost” estimate, but additional information to support the estimate. 

The initial task was to collect data on each weapon system. Pertinent model inputs were collected from various public sources. Flyaway costs were collected for each weapon system and used as the cost input for calibration. Manufacturing complexity for structure and electronics were the key input values solved for via calibration. The calibration results are displayed in a line graph, depicted in Figure One below.

Figure One. Calibration Results for each Weapon System

We then translated all calibration input data and calibration results into a predictive input file. Estimates were completed for each weapon system. All results were reported in the form of a graph depicting average amortized production costs, average flying hour cost, and average operations and support costs for each weapon system. 

The assignment could not have been completed without the capability of the PRICE Models. Model calibration was a critical task. Only a few pieces of data were required: quantity produced, production schedule, and mass. 

The model’s capability to solve for values for manufacturing complexity and a graphical depiction of the results enabled the client to quickly understand the results even though some of their personnel were not familiar with the PRICE models. Do you have a question about should cost?  Post it and we'll do our best to answer your question.  Need help? Contact one of our experts for assistance.

In the February 2011 issue of National Defense, I was struck by the article “Uncertain Path Ahead for Military Truck Fleet”[1]. This article centered on the best strategies for modernization of the aging fleet of Humvees. The recapitalization of 150,000 Army and 25,000 Marine Corps Humvees is creating a “fix or buy new” dilemna for decision makers. According to the article, GAO analyst Michael J. Sullivan should include a “cost-benefit analysis that would minimize the collective acquisition and support costs of the various truck programs, and reduce the risk of overlap or duplication.

The TruePlanning model is an excellent framework to conduct the vigorous cost-benefit analysis called for by GAO.  Having recently completed in-depth AoA’s on two high profile programs, outstanding results were obtained and used by decision makers at the highest levels.

Conducting an AoA using the TruePlanning framework and models would introduce the type of rigorous analytics needed to support the DoD’s vehicle strategy while satisfying the GAO call for cost-benefit analysis. Within the model, each alternative could be structured for both its acquisition and lifecycle profile. This would contain Humvee recapitalization profiles for armored, unarmored and even vehicles that have surpassed their economic useful life. In addition, other alternatives such as JLTV, MRAP, next generation Marine Corps personnel carriers and new production Humvees could be modeled as well. Cost-benefits can also be modeled via TruePlanning’s specialized benefit objects.

In sum, complete force-structuring analysis can be accomplished within the TruePlanning framework. Coupled with optimization tools such as ModelCenter, decision-makers have an analytical way of removing uncertainty for modernizing an aging truck fleet balanced with economic realities.  If you are interested in how force-structuring can be accomplished within TruePlanning, I would be happy to share with you a paper a presented at DoDCAS last year on the subject. Just a post a comment with your request.

My June blog entry suggested the use of parametrics in real-options valuation. This month, I’d like to offer the generalized use of our type of modeling in valuing tangible assets. 

Typically, fundamental analysis evaluates the intrinsic value of securities. I won’t attempt to compete with Warren Buffet here. But it is certainly the case that a company, or portfolio of securities reflecting many companies, is based in part on the market value of its product assets and their potential for future earnings, as well as other objective and subjective considerations.

In parametric estimation, we take a top-down approach to developing models of estimating ultimate acquisition and ownership costs. In the case of the former, I’d argue that we can readily… and uniquely… estimate operating costs for companies developing and selling, say, technology-based products.  Marketing can determine pricing, based on their competitive landscape analyses and market-demand for unmet needs. 

We are in an excellent position to complete the forecasting of earnings (and hence, discounted cash flow) using our parametric methods to evaluate a product-system’s should/will costs. Anyone who does detailed bottoms-up budgeting for “go to market” expense, as well as production delivery, would find value in our modeling.  

And again, once estimated costs are subtracted from revenue forecasts, the netted estimate of earnings and cash flows will allow for traditional market value assessment of this asset or entity. For example, your organization needs to compare economic potentials of emerging new software products. There are no balance sheets. There are no income statements. Yet. 

Now your sales and marketing function has a good independent sense of revenue opportunity. So it’s left to you to estimate the costs of developing and delivering. Independent parametric estimation is the answer. No idea on sizing, either SLOC or function points? No problem. 

Data-driven True Planning has years of data modeling that allow you to run application-specific calculators. In addition, you can take advantage of calibrating actual data from similar projects. Likewise, this process of valuing assets holds true for IT infrastructure products as well. Cloud computing, SAAS and ERP are all further examples of where new IT/software products are emerging… and need estimating as well as financing via valuation.

I think parametric estimating has significant value commercially in the estimation of value of future product assets, and consequently their companies and associated securities.  What do you think?

TruePlanning 2010 SR1 estimation software is now available as an upgrade for existing PRICE customers. The most significant update to this version of TruePlanning is the capability to use both parametric estimating models as well as analogous data to produce estimates. This capability validates and increases the defensibility of estimates.

TruePlanning provides a framework that allows content driven parametric models to be estimated in one system. Most notably, hardware, software, IT and Systems of Systems (SoS). No other commercially available estimating tool can make that claim. However, whereas in previous versions estimates relied on parametric models which are based on industry benchmarks, now users can also incorporate their own data for analysis. Customers can import organizational data to TruePlanning, run regression analysis on that data, and further validate their estimates. So now estimates can be backed by internal organizational data as well as external benchmark data, which is a powerful way to defend an estimate.

To view complete details of this new feature as well as other enhancements visit our New Release Info page. 

Last week I gave a webinar which detailed the PRICE perspective on Should Cost & Will Cost Management. The responses I have received have been very positive and also informing. For those of you who could not attend you can view the recorded version of that webinar here.

Below is a brief summation of that presenation and some key takeaways.

The Under Secretary of Defense issued a memo late last year. The thrust of the memo was the current need for greater efficiency and productivity in defense spending. His guidance contained 23 principal actions for improving the efficiency of the department organized into five initiatives: (1) Target Affordability and Control Cost Growth; (2) Incentivize Productivity and Innovation in Industry; (3) Promote Real Competition; (4) Improve Tradecraft in Services Acquisition; and (5) Reduce Non-Productive Processes and Bureaucracy.

One of the principals outlined in the first initiative is the idea of driving productivity growth through Will Cost / Should Cost management. In my view, Should Cost is "the realm of the possible" and Will Cost is "the domain of the probable". Simply put Will Cost is a forecast of a program’s cost …” based upon reasonable extrapolations from historical experience.”[1] Whereas, Should Cost is an analysis of what the program ought to cost given concerted efforts in economy and efficiency by the contractor. “A should cost analysis results in an, …” Approximation of a contract-price, developed by the customer’s accounting, engineering, procurement, and other costing staff.” [2]

Should Cost analysis for DoD was first applied by the US Air Force in the early 1960s. Over time this practice matured to where in 1972 it was declared “A Multimillion-Dollar Savings” in an article written by Major David N. Burt in the Air University Review (September-October 1972). Major Burt describes the evolution of the practice commencing in a thorough discussion of a “new” alternative approach. He goes on to describe a five phase approach spanning one to four or more months consisting of a very large team which includes actual on-site (contractor) investigation of contractor practices and operations. There are issues associated with both of these concepts.
 
First, a Will Cost estimate is a business as usual view which contains all of the characteristics of both good and bad production and management practices. Estimates based on Will Cost have the effect of perpetuating previous inefficiencies by providing a flawed benchmark. Secondly, a Should Cost analysis as described by Major Burt is both time consuming and costly to implement. Furthermore, Secretary Carter, in his November 3, 2010 memorandum to Military Departments and Directors of Defense Agencies declared his desire …”to establish “Should Cost” targets as management tools for all ACAT I programs… and to establish by January 1, 2011 …”’Should Cost’ estimates for ACAT II and III programs… for component MS decisions.”

Clearly Secretary Carter is serious in regards to achieving productivity growth and soon. However, given the timelines, the cost of a traditional “Should Cost” analysis, and the problems associated with a “Will Cost” approach,  how can the Military Departments and Defense Agencies meet the “beyond objectives” outlined in the November 3rd memorandum?

One solution may be utilizing a parametric approach. A parametric estimating approach will reduce the time and resources required while also providing an external benchmark of industry standards for similar systems. Given the pace with which agencies are expected to move its probably an approach many should consider.

Bob Koury
Senior Research Analyst, PRICE Systems

In last month’s blog I wrote about Ash Carter’s (Under Secretary of Defense for Acquisition, Technology & Logistics) Memorandum for Acquisition Professionals, Better Buying Power: Guidance for Obtaining Greater Efficiency and Productivity in Defense Spending (14 September 2010).

I concluded the TruePlanning unified framework and comprehensive cost models, is a tool very well suited to provide the types of analysis outlined in the memorandum. In terms of Should Cost and Independent Cost Estimates (ICE), TruePlanning estimation software provides the industry standard capability to conduct Should Cost and calibration (actual program history) for ICE. Most interestingly and to the point of the Carter memo, TruePlanning has the capability of breaking the “self fulfilling” prophesy of business-as-usual.

On November 3^rd, Ash Carter issued a follow up memorandum outlining specific actions to implement the September 14^th Guidance. For this month’s post, I wanted to point out some specific comments about Milestone A and B actions and specifically how TruePlanning can help.

At Milestone A the memorandum specifics establishment of an “affordability target to be treated by the Program Manager (PM) like a Key Performance Parameter (KPP)…This analysis should show results of capability excursions around expected design performance points to highlight elements that can be used to establish cost and schedule trade pace.

At Milestone B, the memorandum requires ”a system engineering tradeoff analysis showing how cost varies as the major design parameters and time to complete are traded off against each other.” Thus, Integration between parametric cost models and performance models is needed to allow full exploration and optimization of the trade space, treating cost as another design parameter

Did you know that TruePlanning through its integration with Phoenix ModelCenter is a powerful tool to provide exactly this type of analysis? ModelCenter contains a native plug-in to interface with TruePlanning directly. Through the ModelCenter interface, analysis can easily perform Design of Experiments (DOE), Carpet Plot Analysis (trading performance KPP’s against cost) and Optimization Analysis.  If you are interested in seeing some examples, especially system engineering trade off analysis, please get in contact with me and I will send you a few presentations.

I was recently struck by Ash Carter’s (Under Secretary of Defense for Acquisition, Technology & Logistics) Memorandum for Acquisition Professionals, Better Buying Power: Guidance for Obtaining Greater Efficiency and Productivity in Defense Spending (14 September 2010). Within this broad sweeping memo, Ash Carter outlines 23 principal actions in five major areas aimed at increasing efficiency in Defense acquisition.  The first major area covered is “Target Affordability and Control Cost Growth”.

Within this major area, program managers must treat affordability as a requirement before milestone authority is granted to proceed (starting with Milestone A). This means developing affordability targets and treating cost as a Key Performance Parameter. 

What I find really interesting is the critique of Will Cost vs. Should Cost. The memo is critical of Will Cost, or Independent Cost Estimates (ICE). As Dr. Carter points out, “the ICE reflecting business-as-usual management in past programs, becomes a self fulfilling prophesy. The forecast budget is expected, even required, to be fully obligated and expended.” To combat this “vicious cycle”, the memorandum now requires “each major program to conduct a Should Cost analysis justifying each element of program cost and showing how it is improving year by year or meeting other relevant benchmarks for value.”

In my career experience, parametric estimating models such as TruePlanning play a major role in targeting affordability and controlling cost growth. In terms of affordability analysis, TruePlanning contains a unified framework of all elements of program cost (hardware, software, IT and Systems) and has built-in capacity to interface with engineering optimization tools such as Model Center. Through this interface cost can be treated as a Key Performance Parameter (KPP) for optimization and engineering trade off analysis.

In terms of Should Cost and ICE, TruePlanning provides the industry standard capability to conduct Should Cost and calibrated (actual program history) for ICE. Most interestingly and to the point of the Carter memo, TruePlanning has the capability of breaking the “self fulfilling” prophesy of business-as-usual. Using a calibrated TruePlanning model for ICE, estimators can change key engineering and programmatic parameters and see the impact on cost. For example, parameters such as requirements stability, engineering complexity and team composition can be quickly changed to assess a new program’s reality while still taking into account past performance history.

As the Carter memorandum points out … “the ability to understand and control future cost from a program’s inception is critical to achieving affordability requirements.” Because of TruePlanning unified framework and comprehensive cost models, it is a tool very well suited to provide the types of analysis outlined in the memorandum.

Zach Jasnoff
Solutions Architect, PRICE Systems

After some recent meetings with clients I am sensing some confusion on how to estimate software reuse. I think part of the problem is in the definition of reuse, so let's start with a definition and then address the estimating issue. Software reuse is defined as “the use of existing software, or software knowledge, to build new software.” This definition came from Wikipedia. From a estimating software costs perspective the above definition is part of the problem. The definition should read: "Use of existing software with no changes for operation in the new software program.” 

If the existing software is going to be changed, re-written or modified to operate in the new program, it should be modeled as software adaptation. In this case the software will require some amount of re-testing, and software integration. Software that is being re-used has been fully tested during the original development program. In this case the reused software does not have to go through full up integration and testing. Rather it will go through a regression testing (computer aided testing) to insure it is still operating correctly.

If the software is going to be re-used as is, then clients should use the TruePlanning  “Software COTS” cost object to model and estimate. The purpose of modeling is for integration control. External integration should be set to a value of 0 to 1.0. A value of zero implies that there is no additional integration effort. Values less than one reduce the amount of model calculated software-software integration effort. The reused software can be modeled as a software component. However, do not include software adaptation or new software with the reuse data. This will overstate the integration effort. 

Some of us remember taking the Iowa tests during our early school days. The Iowa Tests of Basic Skills (ITBS) are standardized tests provided as a service to schools by the College of Education of The University of Iowa. The tests, administered to students in grades K-8, became a national standard for measuring scholastic aptitude – I was educated in Pennsylvania.

Now out of Iowa comes another test of sorts, something called an Integrity Index Score based upon a proprietary algorithm of an organization called Iowa Live. Iowa Live calls itself, “a growing network of volunteer Citizens & professionals for improving Iowa.” The organization has addressed a variety of issues in the education, health, and government areas. In July, Iowa Live published its comparison of two commercially marketed parametric estimating software products, one of which was PRICE TruePlanning. The comparison was for both estimation of software projects and estimating hardware. If you’d like to see the results, visit the Iowa Live website, where you can also learn more about the theory and derivation of the Integrity Index.  

Bruce Fad
VP Professional Services, PRICE Systems

Ahhhh, the 80s… a challenging (but often confusing) time in an evolving computing world.  Working in 1985 as a software estimator as well as SQA engineer in a quality assurance department that “audited” real-time projects using new concepts like OOD & OOP… well, you get the picture.  It was a great time to get immersed into great work.  And the good news:  that company’s process as well as its developers were bullish on a young estimation/ quality types asking plenty of questions… as long as they were of the Yes-No variety.  And ask I did.  Writing and using those checklists was great OJT, above & beyond adding their value of verifying/ enabling healthy development activities. 

Less than two years later, SEI’s Walt Humphrey formalized his Capability Maturity Model with its five levels of software process maturity.  These “CMM” levels are still used by many organizations and estimating tools, including within True Planning’s “Organizational Productivity Calculator.”  Could the CMM assessment be supplemented to include cost-driver questions for purposes of parametric estimation?  It worked in my SQA audit days. 

In fact many estimators (if only because they can’t get on an SME’s schedule twice) take the opportunity to ask qualitative and quantitative questions.  Integrating both lines into one interview should still be received as a healthy value-add.  Whether estimation is resident within a quality or financial function is moot.  We have the entrée to support both costing/ planning and productivity assessment.  A good example of an integrated approach is the David Group’s Project Profile Worksheet, cited in the text “Function Point Analysis” by David Garmus & David Herron.  Less comprehensive checklists are likely out there too, including methodologies proprietary to individual companies. 

The thought today is that the future is now and structured approaches, called audits or otherwise, will enable good practices as well as illuminate new approaches too.  In Wall Street, regulations are only good in controlling past (known) bad behaviors.  In just as creative Software, process rules help developers maximize their productivity towards current & future good behaviors.

The key cost driver when estimating software costs is the size of the product. The problem is that there is no perfect technique available to measure and quantify the size of software. The two major techniques in use today are Source Lines of Code and Function Points.  Today we will talk about Source Lines or Code or SLOC.

Source Lines of Code measures logical lines of code. It takes some of the uncertainty out of physical line of code measures by counting only complete statements (which can cross over more than on physical line). SLOC excludes comments and blank lines.

SLOC has several advantages:

·         Easily counted by automated tools, which can be configured with an organizations definition to produce consistent counts. Link to free tool from USC is provided below.

http://sunset.usc.edu/research/CODECOUNT/download/2010/UCC_Release_Notes_v.2010.07.pdf

·         Provide visibility into technical progress as projects proceed through design, code and testing.

·         Can be used to develop historical databases of past project size, which enable the more accurate prediction of size of future similar projects.

·         Design, Code and Test change to modified software can be specifically quantified

SLOC has several disadvantages:

·         It’s very difficult to predict SLOC on new programs prior to design

·         Different programming languages will require different amounts of SLOC to implement the same functions. This makes summary measures of size on multi-programming language products difficult

·         SLOC is difficult to map back to product features or requirements. Which makes usage of EVM difficult to apply to SLOC based SW projects. 

·         SLOC is a meaningless number to non Software Engineers (without detailed explanation)