SOFTWARE DEVELOPMENT COSTS AND CHOICE OF TOOLS
Back on topic
With the emphasis that any manufacturer puts on the fact that they invented a new technology it is easy forgotten that the first interest of managers is the fact that they want solutions to any problem they meet in their daily work as soon as possible and with the least possible costs. Technical knowledge is a totally different field of interest. It is not uncommon that, due to the "marketing seasoning" put on the message they bring to you about this hot new great fantastic tool, you, as a manager tend to believe that this great new tool speeds up development. If that is so, then by all means do read on!
The content of this article is meant to bring you, as a manager who is held responsible and accountable for budgets, back on topic, get your computer application as soon as possible to the least possible costs.
The problem of software calculations
It may not be an unfamiliar fact that software projects have a strong tendency to run over time and logically over budget. Not something that pleases managers. There are a number of factors that lead to the miscalculations of projects. One of them is the fact that developers have one main focus, solve software problems. During this process keeping track of the time has a low priority. A similar situation can be experienced by yourself, if you are in a process of creativity it might very well occur to you that all of a sudden you look up only to realize: "WHAT, is it that late already?"
Another factor could be "requirement creep", either due to a poor analysis of what was needed or due to a fast developing market new requirements could come up and others could fade out. This last factor can never be completely overcome. However, if you have facts that speak for you and a co-operative software department it should not be much of a hassle to bring the message to upper management that more time/money is needed for the development of those new specifications.
Smart tools for free
It is, when you are a member of higher or middle management, of course not your responsibility to make an analysis of the requirements. For that you have an information engineer or you hire one. Your responsibility is the budget and the time needed. Maybe you even invite several possible contractors for a bidding. The functional specifications document, created by the analyst, is then used as input for that bidding. Biddings can be done in two ways. One is to trust that the bidders know their jobs and that you can rely on the figures they calculate. In my, maybe not so humble opinion, this has happened way too much in the past and the stories of projects running over time and over budget are way too well known. The second option you have is to use a simple tool.
Construx, a Seattle (WA) based company has developed a tool "estimate" that you can use to calculate the time needed, based on a few parameters.
The tool can be found at
. In 7 steps you will have at least a fairly good idea of the potential costs for a project you are about to start.
Introduction of "Estimate" the secret right hand of the manager
Educated guesses are hard to make in an area where, so it seems, even the best of programmers are not able to give you an accurate estimate. Steve McConnell, CEO at Construx has done many projects and had a big interest in indicators. This interest, combined with his knowledge of software development lead to the development of Estimate.
After downloading the tool and installing it on your computer you can run it. The installation is fairly simple and straight forward, no hard questions, no registration is required, although there is a possibility to do so. The advantage is that you will be informed about any updates on the software. The tool will run without registration nonetheless.
Double-clicking on the icon on your desktop brings up welcome screen:
The first screen after you skipped the welcome screen is this:
You need a project name first, thus making it easy for you to retrieve it.
The next screen is about the type of application you need. As data is one major source of information your interest could very well be a data related application. this is defined as a business system. Not an Internet system, just a simple one that might run on the company network. Hence the choice for a business type application. The subsystem is the same.
As you can see above you have a rich choice of project types.
The next step is to determine the phase in which the project is. Did we just finish a feasibility study? Or do we have a detailed-design complete?
For the sake of this article I choose the "detailed Requirements/UI design complete" phase. Typically a phase for the bidding.
Now we need some parameters. Maybe you have a very good reason to want the application to be ready at a certain time. A Tradeshow where you want to run the application as a demo, maybe an important board meeting... So what we know is the time in calender months and maybe, the time in staffmonths you want to assign to the project.
Two other parameters you might need are the priority of short schedule and priority of low effort. Both are directly cost related.
In this step we determine the unit we will calculate. Many analysts use functional points analysis as a method, however, other possibilities are available as well.
The ultimate step, what tool do you choose. Here we come at the point where all good arguments can be swept off the table by one simple fact. Microsoft sells Visual Studio .Net as the latest, hottest, nicest and coolest tool to have. C# (C sharp) as one of the tools they promote very well is the tool we first choose here. Let's see what the result will be.
In the graph on the main form of Estimate you see two graphs. Both graphs have a white box with red border. This is the area where you set the time borders. 20 calendar months for development, 34 staff months for effort. In the above graph you see the calculations made from a Monte Carlo simulation. The black cross points to the most likely time needed for development. This is shown once more in the lower graph. The nominal plan for this development is 73 staff months, with a delivery date of about 15.4 months and a peak of 7.4 persons working on the project. In case of an optimum plan, that is, if the world is perfect and no unforeseen problems arise, you have a 33 staff months effort and a delivery of 18.7 months. As said the latter is when everything is alright. However, a staff effort of 73 staff months is way over budget.
Let's take a look at other tools and there influence on delivery time and staff effort. There are 4th Generation tools that are completely data centric in the development language and that are completely Object Oriented.
We were talking here about Microsoft C# first, let's take another look at tool from Microsoft that has just this, Microsoft's Visual FoxPro, a tool that has a strong data centric language and that, in its current version (8) can connect to any database, either MS SQL, Oracle or MySQL of even Access databases.
We select thus the 4th generation tool. Therefore we click in the "scope" area on the main screen and in the dialog that pops up we select 4th Generation (RAD environment).
This leads to some unexpected results.
Once more, the overall time box still stands. Maximum of 20 months to delivery, maximum of 34 staff months.
- According to the nominal plan we need a staff effort of 23 months (11 months less then the budget allows.) and a delivery schedule of 10.6 months. (9.4 months less then budget allows.)
- In the optimum plan (the perfect world scenario) we need an 11 staff-months effort (23 months less then budgeted) and we have a delivery schedule of 12.7 months (7.3 months less then budgeted).
Using Visual FoxPro as the development tool, both plans, nominal as well as optimum, fall well within the range we did set in terms of time and costs. Allowing even for a slight delay if some extra requirements, that might be found along the way, need to be implemented and even allowing time for thorough testing.
As managers with a main responsibility for budgets your main interest is not with the technique. It is not directly your responsibility. What is important however in this context is a correct answer to the question whether any offers made to you are reliable. This way you, the person who is held accountable for the costs related to software projects, can give an educated guess whether or not you might need either more money for the project to succeed or that the company (or in-house dept.) should consider another tool for the development to stay in tune with your budget.
ABOUT THE AUTHOR: BOUDEWIJN LUTGERINK
Programming is one of the many hobbies of Boudewijn. He has worked with computers since 1985 and is the author of two books from Sybex. He has a weblog at
Enter the code shown: