Snap Eng . ineering

How to Use "SnapEng S Estimator"

This app approximates an answer to the question, "how much effort will it take to complete a software project with this many lines of code" based on your prior examples.

It does this by using estimation factors derived from the prior examples you calibrate it with.  Imagine a curve of effort that bends upwards as software projects get bigger.  Large software projects that create more lines of software code are positioned further along the curve.  Small software projects are positioned earlier along the curve.

More lines of code results in more effort.  If you are estimating future projects that are similar to your prior projects (examples), then this app will produce better estimates. 

But they are just estimates.  Estimating project effort based on lines of code is perilous.  The app is performing a paper napkin-style calculation for you.  Don't bet the farm (or your career) on the Effort numbers it produces.  Use them as a starting point and a sanity check for more detailed estimation.  The app in no way has some magically inside knowledge about your future projects.

But if you agree that your future projects can be roughly fit to your calibrated effort curve, then this app is for you.

Calibration

The app comes calibrated but to get useful results, you need to calibrate it with your own prior examples.  Without this calibration set, you are ultimately going to be disappointed.

Start by pressing Reset Sliders.  Next, think of two to three sample projects you know of and note how many effort days they each took to complete and how many lines of software code they each developed.  Start the calibration with the first project by entering the lines of code developed by this project in the top left corner.  The field heading is "Thousands of Lines".  So, a project with 1,000,000 lines of code has 1000 entered into the top left corner.  Tap to the side of the text field to hide the keypad.

The calibration for the first project is now halfway done.  Tap the italic 'i' to inspect the backside of the app.  Enter the Calibration Effort in days and press the Calibrate.  Tap to the left of the text field to dismiss the numeric keypad.  Either the Best factor, the Worst factor or both factors will automatically update.  Press Done to return to the front of the app.  Now, enter one or two more sample projects repeating the same steps. 

Anytime you want to throw out your calibration and start again, press Reset to Defaults to discard your calibration and start with the default calibration.

Characterizing Your Project

Not all project teams perform equally.  Product Complexity and Programmer Expertise are some of the factor that affect any estimate.  Seven of the top factors impacting team productivity get controlled by you using the sliders.  Slide Product Complexity to the right for highly complex projects.  Slide it to the left of low complexity projects.  If Staff Turnover is high, slide this slider to the right.  For each slider, the computed factor is displayed at the right end of the slider.  Factors of 1.0 don't impact your estimate.

It is rare for a project to be far to the left or far to the right.  More often, projects are near the middle of the range.  Press Reset Sliders to return the sliders to their middle positions and apply a neutral weighting for all these factors.

Your first round of calibration applied neutral weighting to each of your sample projects.  If you want, you can recalibrate again, adjusting each time for the characteristics of the sample projects. This is optional, but refines your calibration.

• Product Complexity is a relative measure of how complex the software system your project will build is, relative to other similar systems out there in the World. Sliding this to the right yields higher Effort estimates.
• Requirements Analysis Expertise is considered high when you have people and processes in place that reduce the risk of building the wrong thing or painting yourself into a corner because you did not fully understand the implications of your system requirements.  Sliding this to the right yields lower Effort estimates.
• Programmer Expertise refers to the raw talent, experience and capability of your staff, even if they are working in a new language or development platform.  Sliding this to the right yields lower Effort estimates.
• Process Maturity is how a measure of how well your project workflow functions, how few big decisions you have to revisit and how effective communication is within your team and with the customer.  Sliding this to the right yields lower Effort estimates.
• Architecture and Risk Resolution tells you how well your team manages risk and builds architectures that survive requirements changes and scale well.  Sliding this to the right yields lower Effort estimates.
• Schedule Pressure is high when the project has to deliver early.  Longer schedules tend to produce more efficient project execution.  Sliding this to the right yields higher Effort estimates.
• Staff Turnover can mean people quitting the organization or simply being reallocated from the project to other.  Sliding this to the right yields higher Effort estimates.

Worst Case, Best Case Slider

The very top slider moves between worst and base case.  The Worst and Best factors on the backside determine this range.  It lets you quickly see how the new project you are trying to estimate stacks up again the prior projects you used to calibrate the app.  This slider does not get moved when Reset Sliders gets pressed.

The Effort in the top right of the app is the calculated effort in days to complete the number of thousands of lines of software code you entered in the top left. 

How the "SnapEng S Estimator" Works

A simple formula produces the estimate:

( (Thousands of Lines) to the power of (Non-Linear Growth) ) * (Characterization of Project) * (Worst or Best Bias)

The Non-Linear Growth models the diseconomy of scale that sets in as projects get larger.  The Characterization of the project is all the slider values multiplied together into a single factor.  Finally, the Worst or Best case bias is controlled by the Worst Case, Best Case slider.  When the slider is at the middle position, the app splits the difference between the Worst and Best factors.

Frequently Asked Questions about the "SnapEng S Estimator"

Q: How much can I trust the estimate produced by this app?

A: Never bet the farm or your career on the numbers produced by this app.  The calculated Effort is a starting point and also a sanity check for estimates already prepared by your team or guessed at by your stakeholders.

Q: Can I skip the calibration and go with the app calibration defaults?

A: You can get familiar with the app using the app defaults, but there is just too much variability between organizations to settle on generic app defaults.  Spend the minute to perform the calibration.  At that point, the app starts being meaningful in your context.

Q: The numeric keypad comes up to let me type in a number, but then will not away?

A: You need to tap just to the side of the text field.  Then the numeric keypad with go away.

Q: Should I worry about changing the Non-Linear Growth number?

A: Changing this value adjusts the bend in the Effort curve mentioned at the top of this page.  The app default is 1.15 and it is taken from the COCOMO estimation discussion available on the web.  Check out our links page for more reference material.

Q: Why can I only enter values ranging from 1.00 to 1.99 for the Non-Linear Growth number?

A: Values in 1.05 to 1.20 are considered reasonable non-linear growth factors for software estimation.  1.99 results in almost squared values, which and drives the calculated effort up too fast.  1.00 results in no bend in the effort curve, which is typically unrealistic.  The app is unable to model to model economies of scale for software projects.

Q: Can I save my estimation results so that I can transfer it outside the app?

A: No.  But that's a good idea.  That's for a later version of this app.  First we crawl, then we'll walk.  Remember that you can take a screenshot of the app by holding the Home button then pressing and releasing the Sleep / Wake switch. 

Q: What is the units of the Effort number?

A: The convention is that it is always expressed in days of effort.  For this reason, you need to calibrate using days, too.

Q: Can I setup the app to express Effort in hours?

A: Yes you can.  Calibrate the app with your Calibration Effort set in hours, instead of days.  However, you have to stick to hours throughout your calibration and estimation using the app.  You can also Reset to Defaults and re-enter calibration projects using days to get back to the default, days units for Effort.

Q: How do I save my calibration values?

A: They are saved automatically as you enter them, however pressing Reset to Defaults deletes your values and replaces them with the app defaults.  At that point, you have to recalibrate the application if you want your own factors.

Q: Why do the Best Factors and Worst Factors adjust in unexpected ways each time a press Calibrate?

A: Rather than have a Set Best Factor and Set Worst Factor button, a single Calibrate button is provided.  This stops you having to decide ahead of time whether the calibration project you are using is a Best or a Worst case scenario.  Each time the Calibrate button is pressed, the app back calculates the factor for this current calibration project.  It then compares this factor to the existing Best and Worst case factors.  If the latest factor is worse than the Worst Factor, it replaces the Worst Factor and makes the Worst Factor the new Best Factor.  If the latest factor is between the Best and Worst factors, the app replaces which ever existing factor is closest to the latest factor.

Q: Why does adjusting the Characteristics sliders swings my estimate through a wide range?

A: Imagine a project with high staff turnover, low programmer expertise and high complexity.  It's likely a death march project, but will get done once a enough blood, sweat and tears occur.  This is what the high estimate alludes to.

Q: Where does the estimation algorithm originally come from and why isn't it more complicated?

A: Check out wikipedia.  The formula uses numbers to says, "as systems get larger, they rapidly become harder and harder to complete."  It also uses numbers to state, "you can apply multiplication factors to an estimate based on known characteristics of the organization performing the work."  We are building on the work of Barry Boehm and although his work originates from the 1990s it still rings true today.  We boil the math down into a number of rules of thumb:

• Keep systems as simple as possible; complexity is typically the largest cost driver  
• Stay on top of your system requirements and understand their implications for your implementation as early as possible
• Emphasize raw programmer capability as opposed to specific language or platform knowledge.  A great team member can handle many different technical contexts.
• Keep your team together.  Staff turnover bleeds your project and investing in them along the way likely has a positive return. 

Q: What does the "S" stand for and why the strange name?