Fagan Inspections And Software Cost

August 20, 2013 · Filed Under General · Comment 

Fagan Inspections have been around since the 1980′s as an effective way to reduce software cost by finding and removing errors early.

As Wikipedia says:

Fagan inspection is process of trying to find defects in development documents such as programming code, specifications, designs and others during various phases of the software development process.

Yet the vast majority of organizations are not interested, or at least are not able, to implement them. In my own career, I have seen teams kill inspections on several occasions with the poor logic that they take too much time.  What a shame.  Looking at the data (the data is old but the approach is still completely viable) we can see that if software organizations, using waterfall, Agile, or anything in between, could achieve significant software cost savings.    Here is some of the data:

Company Cost to Repair During Inspection Cost To Repair During Test Cost to Repair after Delivery
IBM $48 Per Defect $61-$1030 per defect 117 * more than if caught during inspection
AT&T 1 Unit 20 Units
JPL $105 per defect $1700 Per defect
Shell 1 unit 30 units
Thorn EMI 1 hour 30 hours
Infosys 1 unit 3 – 6 units
Source: Radice, 2002 via Oxford Software Engineering http://www.osel.co.uk/presentations/fitsbnwtf.pdf

 

I believe there are at least three reasons for the failure of Fagan inspections:

  1. Developers don’t like to critique each others’s work negatively
  2. The “why isn’t Jonny coding Syndrome”  People think it is not as productive as don’t their own work
  3. Lack of training and discipline

Software estimation and software cost estimation provide the potential for improvements.  But it takes management discipline to really make things happen.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.




Cost and Risk of Mobile App Development

July 9, 2013 · Filed Under General, Software Estimating · 1 Comment 

Lee Fischman (one of Galorath’s leading researchers) gave a webinar discussing mobile applications, their cost and complexity. Below is his blog and the actual slides for “Moving Target” How Much Do Mobile Apps Cost To Develop:

When we recently looked again into mobile apps, no surprise, we found a vast and sophisticated ecosystem dedicated to their development and maintenance. Just as with any other platform, mobile apps in terms of complexity vary from extremely simple to the “sky is the limit”. What differentiates the mobile platform is its extremely rapid evolution across the board: front end technology, back end infrastructure, market and participants.

Effort In Developing Mobile Apps

There of course is not one mobile platform but at least three major contestants: iOS, Android and Windows Phone. While the development tools vary for each platform, a surprising number of very robust authoring tools are being used by developers for cross-platform development. These tools either produce target code for each separate platform or towards the one major common standard sweeping across the web: HTML5. All the same, there is no shortage of work for dedicated platform developers.

The perhaps more compelling story in mobile app development is not what users see, or even what they are holding in their hands, but the back end that supports these apps. Any major application (Foursquare, Twitter, Instagram, etc.) has built out an infrastructure to support availability, performance, reliability, scalability, manageability, and – because server time can get very expensive – efficiency. A many-layered vendor ecosystem exists to support these goals.

Estimating mobile app development with SEER-SEM is similar to any other estimating exercise. Along with estimating the app (SEER-SEM supports development in Java, Objective C and so forth) there may be server components, frameworks, and integration with other systems. All of these can be estimated in SEER-SEM.

 

The actual recorded webinar How Much Do Mobile Apps Cost is available by signing in to the Galorath library.

Thank you for reading "Dan on Estimating", if you would like more information about Galorath's estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.




Is Agile Software Development Cheaper? Depends on What “Cheaper” Is

June 27, 2013 · Filed Under General · 1 Comment 

I read an excellent discussion of “Is Agile Software Development Cheaper” by Kennith Grant.  This discussion was similar to one I had last week myself.   He pointed out that the typical answer “we will deliver every few weeks and not building features people don’t want”  was the normal answer but that really didn’t answer the CEO’s question.  Cheaper in the CEO’s context “cheaper” means “a project can be completed with the same or smaller amount of people for the same or shorter length of time”

AGILE VERSUS WATERFALL IS LARGELY APPLES TO ORANGES: “If we have a software product with a known and unchanging scope and all other things are equal, will it be cheaper to deliver the product in its entirety using an agile methodology rather than using waterfall?” The short answer to this question is no. Agile has, especially with Scrum, a degree of ceremony, and in this make-believe scenario that would get in the way of pure analysis, design, build, test, etc. As you can see, this degree of ceremony would slow things down, hence making a project more expensive.

But the real questions should be more like “if rather than building the program in its entirety, we build only the critical functionality and reduce rework the answer is different.

agile development cycle

AGILE USUALLY CHEAPER IN THE REAL WORLD: If we build functionality the user wants and with feedback so we stay on course is the program cheaper… LIKELY

STANDISH FOUND MUCH WATERFALL FUNCTIONALITY NOT NEEDED: The Standish Group once found that when requirements are specified early in the lifecycle, 80 percent of the functionality is relatively unwanted by users with 45 percent never used, 19 percent are rarely used, and 16 percent are sometimes used.

VIABLE COST & SCHEDULE ESTIMATES ARE POSSIBLE FOR DECISION MAKING: But in answering this question from a pragmatic view, estimation IS needed up front to understand the probable scope and the range of cost and schedule.  For programs of any substance management needs this information to make proper decisions.  I sometimes hear agile people say something like “can be done at any time, will deliver constantly,  and can’t tell you when the customer will have achieved their full business value. “  Further, I have seen Agile programs that took their user stories, assumed this was the complete list up front and forgot all the volatility designed into an Agile program, with change encouraged and new / changed user stories likely coming up regularly.

CHEAPER NEEDS TO CONSIDER TOTAL OWNERSHIP COSTS, NOTE JUST DEVELOPMENT: Again, developers are rightly concerned with development, not maintenance.  But what about the C level…  If something can be developed using Agile but is a nightmare to maintain (we did minimalise on documentation, for example) we may be bloating the maintenence portfolio with surprises.  And management hates surprises.  Using SEER one can evalaute both development and maintenance.

Some of the risks that are often ignored and should not be:

  • Using User Stories as size doesn’t mean they won’t grow / change
  • Requirements volatility can be even more drastic (design on the fly)
  • Risk of lack of integration / regression testing from sprint to sprint
  • Requirements growth due to regular wish lists
  • Poorly constructed user stories may require modifications
  • More

And some of the SEER parameters that model Agile are:

  • Requirements Formality
  • Requirements Volatility
  • Personnel Capabilities – Analyst and Programmers
  • Familiarity with the Process
  • Process Maturity
  • Staffing Complexity
  • Development System Volatility
  • Automated Tools Usage
  • Testing Level
  • Quality Assurance Participation

Recent briefing covering Agile methods and modeling Agile cost, schedule, and risk

Here is a link to Kenneth Grant’s blog “Is Agile Cheaper

 

 

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.




ICEAA Briefing Slides: Other Uses of Parametric Models

June 19, 2013 · Filed Under General · 1 Comment 

I had the good fortune to be asked to brief other users of parametrics at the ICEAA conference training.  My slides were newer than those distributed to the group so I told attendees I would offer those slides on my blog…  This was material originally provided by others and taught by myself this year.  In preparation for teaching I did update the slides substantially.  I also included much of the original content in the slides.

The bottom line is whenever you want to make decisions, do tradeoffs, establish the most affordable approach or understand risks and risk analysis, parametric estimating equations can help. Here are the slides:  Other uses of Parametric modeling slides.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.




Affordability Analysis: The Role of Process, Cost and ROI Modeling In Improved Program Performance

June 15, 2013 · Filed Under General, Presentations · Comment 

Here is my briefing covering affordability process “Affordability Analysis: The Role of Process, Cost and ROI Modeling In Improved Program Performance” I will be presenting at the ICEAA (SCEA) conference in New Orleans.  The bottom line is you can make viable affordability decisions using repeatable processes both for affordability and for estimating.

The abstract follows:

Affordability analysis as part of decision making may be the biggest edge of the decade for both commercial organizations and DoD / government organizations. Affordability has been addressed in the past but never with to the level it is today. In an IT context companies struggle to increase profits and often view IT as a necessary evil: one that consumes resources rather than contributes to the bottom line. However, IT can be a significant contributor when IT decisions are made after modeling affordability in multiple dimensions. In a DoD context affordability as “should cost” and “will cost” are the bywords of the times: attempting to replace past cost / performance failure due to inflexible user requirements or over-specified contractor requirements with realistic trades of cost, schedule, and other key performance parameters (KPPs). New developments and upgrades / new buys can benefit from affordability analysis. A complete affordability analysis estimates the risk adjusted Total Cost of Ownership, return on investment, consistency with long-range strategy, against risk and key technical and performance parameters. In affordability analysis tools are important and repeatable process is essential to success. Hence the 10 affordability process will be covered. Those steps are: Step 1. Establish inviolate Key Performance Parameters Step 2. Identify Affordability Goals & Figures of merit Development, life cycle, payback, ROI, NPV, kill ratio, budget constraints, etc) Step 3. Gather Requirements, Features, performance Step 4. Define baseline alternatives Step 5. Perform technical Design Analysis for each alternative Step 6. Perform cost / schedule analysis of each alternative Step 7. Assess benefits based on figures of merit Step 8. Perform Probabilistic Risk Analysis Step 9. Assess Alternatives & Select optimal Alternative Step 10. Document analysis and lessons learned Each step will be covered and the modeling steps themselves will be emphasized.  

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.




Weaknesses In IT Estimating Practices Can Be Corrected By Best Practices Finds GAO

May 30, 2013 · Filed Under General · Comment 

GAO recently published a report where they assessed cost-estimating policies and practices for eight government organizations to determine how reliable estimates were in supporting affordability, budget and program decisions.  GAO reviewed cost estimates for 16 major initiatives (Of course the GAO itself published a cost estimating guidebook  reference),  $51.5 billion of the approximately $75 billion budgeted for fiscal year 2012. They found that most of the agencies had made progress but needed additional standardization as well as centralized cost estimating.

“GAO found weaknesses were due largely to priority for establishing or enhancing cost-estimating functions and weaknesses in policies to ensure estimates provide  informed decision making, realistic budget formation, and meaningful progress measurement”. Many estimates did not include total life-cycle costs, such as costs for operating and maintaining the system, did not document the basis of the estimate (methods, data, etc.)  were not updated when the program changed, and did not account for risk and uncertainty.

The 16 major acquisition programs had developed cost estimates and were using them, in part, to support program and budget decisions. However, all but 1 of the estimates were not fully reliable—meaning that they did not fully reflect all four characteristics of a reliable cost estimate identified in the GAO cost-estimating guide, comprehensive,well-documented, accurate, and credible. While it useful to  look at weaknesses and how to correct them, I think the most important thing is what can we learn and how can we get to the next level.

GAO Estimate Findings

Read more

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.




Reasons For Estimation Failure

April 23, 2013 · Filed Under General · Comment 

Estimation is a core process that can be a root cause of project success or failure. A  paper by Andy Nolan of Rolls Royce and published by INCOSE (I can’t locate the original paper on the web) identifies the 10 reasons for failure of estimation..  He also identified the allocation of estimation error.  19% being attribute for estimation failure:due to tools, 37% related to process issues, and 44% related to behavior issues.

rolls royce estimation failure

Here are each of the 10 reasons:

1 Scope creep: Often the result of not having a clearly defined scope and/or not tracking and declaring changes to scope.

2 Poor input to estimate: This refers to poor quality requirements or objectives, leaving the estimate open to risk and scope variation. The estimate is “built on sand” but the estimator does not factor for this or clearly express the uncertainty as a 3-point estimate.

3 Failure to clearly define the initial scope: Items may be missed out or there may be a failure to declare assumptions. This will make the project vulnerable to scope creep or conflict later in the project as all parties argue over what is in scope and what is out of scope.

4 Unrealistic expectations and assumptions: Optimistic assumptions that it will go right this time. Claiming benefit from improvements before they have been demonstrated. Overruling the estimate.

5 Failure to declare, track and reduce risk and uncertainties. The project may then be vulnerable to unnecessary risk.

6 Lack of internal peer review: Failing to benefit from peers‟ experience. A review is a simple and cost effective way to improve estimate “Quality”

7 Lack of estimation experience: Estimates generated by a person who may not have experience in estimating or in the subject being estimated.

8 Failure to consider environmental factors: Undeclared and untracked elements of the environment can change – having unexpected and “dramatic” effects for examples, loss of key individuals, change of supplier, a more complex organisation, etc.

9 Failure in the estimation tool/process: The tool or process may be unable to deliver the desired accuracy. It is essential to measure and declare the estimate tolerance of any tools used.

10 Lack of estimation process/technique: Failing to apply a systematic estimation tool, method or processes. Without this, it is hard to defend the estimate.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.




Apple IOS 7: Adding People To a Late Project Makes It Later

April 11, 2013 · Filed Under General · 3 Comments 

I am an Apple IOS fan.  I use an iPhone and am writing this on my iPad.  And I am a geek so I wait anxiously for the next versions of iPhone, iPad, and IOS. I read the iPhone and iPad rumors at least weekly.  I also get to see the results of staffing and other decisions based on staffing in numerous programs.

Recent batches of Apple rumors state that IOS 7, the new iPhone / iPad operating system is late and Apple may have to ship the newest hardware devices without IOS 7.  Apple’s solution…. Take staff off the Macintosh operating system development and put them on IOS 7. 

 Basic software productivity laws (see law 3 below) state that adding people to a late project makes it later.  This was first observed by Frederick Brooks and documented in his book “The Mythical Man month.” And taking people without domain knowledge just makes things worse.

 Now there is some chance this might help.  so long as their staff doesn’t increase to the point of Brooks Law comes into play. Additionally, absorbing people into the IOS project from outside will cause the IOS core team to slow down as entropy kicks in.  We have developed a set of productivity laws that cover these phenomena.  Some are based on Brooks Law while others are of our own discovery.

Software Productivity Laws:

Software productivity

 

 

 

Read more

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.




Elminating Technical Debt: Easy?

April 10, 2013 · Filed Under General · Comment 

An excellent article on eliminating technical debt… The Question “can we eliminate technical debt”  the answer yes so long as we have all the time and resources to eliminate technical debt based on:

  1. Technical Debt Due To Lack of Analysis: Analyze and fully understand the process you need to computerize.
  2. Technical Debt Due To Lack of best Practices: Write code so that it is perfectly consistent with the best practices of the various technologies used.
  3. Technical Debt Due to Lack of Rework Integration: Change existing code so that it’s seamlessly integrated with the newly created code. This also requires a perfect understanding of the existing code.
  4. Technical Debt Due To Lack of A Test Suite: All the time and resources necessary to create a suite of automatic and integration tests for testing the various features of the written code one by one.
  5. Technical Debt Due To Lack of Technical Documentation: All the time and resources necessary to write the technical support documentation for future changes.

And of course I must add:

6. Technical Debt Due to Resource Constraints: Too few or too many people on the project causing issues as well as inadequate schedules.

7. Technical Debt Due To Poor Planning: Either lack of planning or not re-planning when things change.
8. Technical Debt Due To People Being Human:  People are still human so there will be mistakes that don’t get caught.  That is just life with software.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.




Standard Estimating Gates

March 29, 2013 · Filed Under business value, Cost Estimating, Estimating, General, Thoughts · Comment 

A customer recently asked us for a standard set of estimating points.  And among us we didn’t have an answer off the top of our heads… We looked at PMI, ITIL, COBIT, etc. and found no standard.  We deal with estimating gates all the time… So how come we didn’t have any standards.  It struck me that the estimating points match many of the decision gates, the development gates.  So one of our PMI certified Project Managers called the PMI offices. They said they don’t mandate estimation points or gates since they are so diverse among organizations.  And they suggested where there is a key deliverable, one the project cant live without, that is generally a gate.

 

PMI’s PMBOK states “cost estimates should be reviewed and refined during the course of the project to reflect additional detail as it becomes available and assumptions are tested.  The accuracy of a project estimate will increase as the project progresses through the project life cycle.  For example a project in the initiation phase may have a rough order of magnitude (ROM) estimate in the range of -25% to +75%.  Later in the project, as more information is known, definitive estimates could narrow the range of accuracy to -5% to +10%.  In some organizations, there are guidelines for when such refinements can be made and the degree fo confidence or accuracy that is expected”  In other words PMI remains silent on standard estimation points.

So.. Here is a proposed set of standard estimation points.  These gates are often tied to how an organization funds money for projects.  So they need to be tailored to the governance approaches being used:

 

Concept Level Estimate

Just a finger in the wind to see if the idea is worth exploring or is so expensive as to be impractical.

Business Case Estimate

Estimate in the decision making phase when a project has not yet been authorized, often as part of the business case analysis.

Project Charter and Plan Estimate

Estimate that goes along with a project definition or project statement and estimates scope, objectives and participants in a project as well at the primary roles and responsibilities.

Detailed Plan & Function Spec Estimate

Project planning level where the project team prepares th estimate of how it will move forward.  In Agile projects this may be the overall project estimate rather than individual sprint estimates.

Construction / Deployment Estimate

An estimate to complete of a project that is underway to help keep the project on schedule and cost.

Post Deployment Estimate

This estimate provides information for estimators and others to used such as lessons learned, actual data for calibration, etc.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.




« Previous PageNext Page »