Galorath's Ian Brown will be presenting this paper at the Canada ICEAA conference this week" Too often, organizations that contract for software development services are at the mercy of vendors for cost and schedule estimates. Once a program office releases a request for proposal for software development, it must somehow evaluate the validity of cost and schedule estimates that come back with the proposals. Or a program might have a limited budget or schedule but not a clear understanding of …
El Segundo, Calif.—December 4, 2017— Galorath Incorporated, a California-based software and professional services firm whose customers include the U.S. Department of Defense, announces an exciting development for its SEER® for Software (aka SEER-SEM™) application.
SEER for Software now incorporates the data-centric DoD SRDR dataset. Galorath has prepared a SEER-formatted historical database (SEER-HD) and a set of specialized knowledge bases that incorporate the sanitized version of the DoD SRDR database.
The update will enable DoD users of SEER for Software to leverage SEER-SEM capabilities using a familiar dataset. This database can now be used directly in SEER-SEM for estimating, sizing, …
Here are my slides 2017 estimating source lines of code that will be contributed to the ICEAA software costing body of knowledge. It is important to note that Galorath / SEER is size agnostic. Lines of code can work in many circumstances, functional sizes can work well in many circumstances as can other size measures.
There are people who love source lines of code and people that hate them. I have seen people get into big trouble making up SLOC estimates. And I have seen people do a great job of estimating from properly counted analogies or estimates that understood …
I always enjoy the writings of Capers Jones and was pleasantly surprised to see an article in Crosstalk Magazine (which I was also surprised was still published... I recommend it) listing the laws of software engineering. Many of my heros have laws listed in this fascinating article. Of the set of software productivity laws I published Capers chose one "projects that get behind stay behind" to include in the article.
"Galorath’s Seventh Law: Projects that get behind stay behind.
Dan Galorath has a number of other laws, but this one has poignant truth that
I like Agile development. And I have had many stimulating discussions with Agile people about their perception that estimates are no longer needed with Agile development. In some circumstances I agree.
For root level project management, Agile developers essentially are doing a better job of what software has been trying to do since its inception: getting people to collaborate while meeting small goals and working on the most important problems.Agile Shouldn't Replace Estimation and Commitment On Substantial Programs
But the idea that there is no need to provide stakeholders with viable …
Galorath incorporated is size metric agnostic. If it has a relationship to effort we are all for it and our SEER models can use it. Of course we dabble in new sizing methods, from Lee Fischman's evolved function points, to our function based sizing, to web page sizing. That being said, I was very impressed by the word of Roberto Meli, the creator of simple function points and Luigi Lavazzra, the professor that lead the independent verification of simple function point's ability to produce an IFPUG count more quickly.
Here is the bottom line according to Meli:
Software’s 2014 CRASH report’s findings that Agile and hybrid methods being most effective were consistent with Galorath's observations that Agile itself is not so much a methodology as a mind-set. Iterative or incremental development with constant feedback based on frequent builds allow course corrections when costs are low and keep a project agile (with a small a). And while SCRUM type Agile approaches can be very effective, agile benefits can often achieved using hybrid approaches...
"Cast Health factor scores for the mix of Agile and Waterfall are higher than for Agile or Waterfall approaches used separately."
David DeWitt's excellent …
I did the attached briefing on Introduction to software productivity some time ago and forgot about it. And while talking to Capers Jones today about productivity I found it and thought it was pretty good.
It talks about different productivity measures and how to get one that is consistent. In fact I believe the four main criteria are
It cautions " Quantifying Productivity is useful for comparison and estimate sanity checks but steps should be taken to ensure consistency"
Also, productivity, software estimation, and software measurement are discussed as follow:
Productivity: how to measure productivity, …
It was interesting giving a talk on affordability to this group in London. While the UK has affordability as a goal (in fact the conference theme was affordability) they look at it a bit differently. It was interesting talking about price versus cost and the UK prospective.
Another thing that was interesting is the prospective that for IT systems software development is more like 6 to 10 percent of the total ownership cost. But it is the bulk of the risk.
And I got out just before the tube strike began in earnest. The next day I had to walk …
This blog was written by David DeWitt, Director of Software and IT Consulting, Galorath Incorporated. He is a Certified ScrumMaster and has developed and teaches the Agile Estimation with SEER for Software workshops. If first appeared in "Projects at Work"Agile as the Only Methodology?
I was recently at a very large government agency and was surprised to learn that they had declared Agile to be the only “methodology” to be used on future projects.
My first question was “Why?”
My second question was, “Which Agile methodology?”
I will discuss why I asked the