In the beginning…

In the good old days, software development costs were purely based upon the number of man-hours that were put into it. This was good for many techies, as many didn’t have a clue of how to deliver the solution and a lot of trial and error was involved. Most software developers were usually put in a department called R&D ). This was bad for the software industry as it meant that costs were ridiculously high for even medium sized projects, which meant that most investors kept away from such endeavors. None could question the situation, as nobody knew any better (least of all, the techies).

Then slowly, metrics was implemented into the development process and all that changed. Now, if most of the programmers could deliver 1000 lines of acceptable code in a day then that was considered a standard output. This was good with languages like COBOL as reusability of code was mostly not possible. One referred code that was already written, and reworked it (easier said than done).

Then, slowly the C language became popular, and soon, just churning out lines of code was not enough. The C language had in-built libraries which took away some of the joy of screwing around with lines of code. Furthermore, programmers could put lines of code into a function and then reuse that function in other functions. So then, the focus changed more towards how many functions were being developed. So if you could break down your code into many functions, it meant your output was higher. Real cool. Whenever a function appeared to be more than 20 lines, there was a possibility for splitting it and increasing your output.

Then came C++ and it really complicated the estimation work. Now we have components, objects, classes, libraries, and what not. Something called system design was critical in deciding how to reduce the number of man-hours involved. Good design meant that entire components/sub components having thousands of lines of code contained in hundreds of functions that were placed in a few hundred classes could be reused. And within the components too, several classes and functions were reused. Even this is acceptable provided you have a complete, detailed, and approved design in place. Such a design would help determine the number of functions and lines of code that would be required.

So, what really is the problem?

These days, the cost of the project is often fixed before the design is done, and sometimes even before design has begun. Estimation now becomes more of guesswork based upon experience that was gained by screwing up earlier estimates. Without the design, it was quite impossible to know how many lines of code/functions/components/objects would be required. The estimator should rely on data and documents available before one starts the design, such as the functional and non-functional requirements, workflows, and use-cases. Therefore, requirements gathering and analysis is very critical to the project's estimation (design, development, and testing).

Using these documents, the estimator may create an object hierarchy tree simultaneously. The object hierarchy tree can help identify different levels/types of objects to be created, what is expected from these objects, and even some attributes for the objects. Therefore, without having an application design in place, the scope of work to be done, in terms of functionality required, can be identified.

Next, we need to determine the output of a typical team member. Some companies prefer to segregate team members depending upon the role, position, and pay scale of the team member. A team member's output should be proportionate to the role, position, and salary. A team member's work includes ideas, suggestions, discussions, research, and coding. But their output involves design, documentation, test case designs, coding, debugging, and testing. Usually, an architect would not do any coding. Neither would a tester nor would the project manager. So, the deliverables of each of these is taken differently, as below:

Role

Output

Programmers

Number of functions coded.

Designers

Sequence diagrams, classes (with functions) designed, associations.

Architects

Requirement analysis. Number of major components and tiers designed. Classes and objects approval.

Tester

System functionality tested.

Business Analyst

Requirements, workflows, and use-cases.

Project Manager

Deliverables as per the contract, resource management, fire fighting.

There are other roles like deployment manager, SQAs, domain consultants, and what not? The problem here is that many estimates are done before one can determine how many man-hours are involved by each of the above roles. For this article, I assumed that all team members are equals in terms of efforts and salaries (extreme programming disciples would appreciate this).

How to estimate an application cost without a design in place?

Each company determines the output it expects from its team members. Let us call the average output of a team member per man-hour as the unit output (u.o.). Assume that one has to deliver an end-to-end login module's functionality for an application. The time spent on the login functionality should include the corresponding time required for gathering the requirements, doing a requirement analysis, architecture inputs, form design, object/class design, implementing the business rules, data validation and storage, framework (i.e., code for login module's constants, enumerations, utilities), testing, debugging, deployment up to user acceptance, etc. Now, the estimator has to figure out how many man-hours it would take to complete the login module, keeping all these factors in mind. The sequence of work and dependencies should be considered as they do cause delays in completion. For example, form design should be done first (all the way up to acceptance by the customer), then object design (up to acceptance by the architect), followed by coding (for business rules, calculations, and data validations), internal testing, and user acceptance testing. A wise estimator would always take support from other people to understand the scope of work to do a given task.

Map features of older projects to those in new projects

Login module is a common feature of most applications, so we could justify it if the total effort to complete all these activities is 20 man hours. Now, if it costs the company rupees 700/- per hour (for a programmer, and workstation including hardware and software), then the basic cost of developing the login screen is 20 (man hours) x 700 (Rupees) = 14000.00 (Rupees). Ouch! Did that hurt? Is it too much (time/money)? For too little? Better give it more thought to justify both. J

Estimators should also try to map older projects to new ones. This would give them an idea of the broader picture of the time spent, and they could then try to distribute the man hours across the application's modules and phases.

Convert complex stuff to simple stuff

The number of hours required to develop a simple registration feature (end-to-end) would be within the abilities of most estimators. The simple registration form would include a Username, Password, and Email ID. In my opinion, this is approximately the same as the login page, so let us put 20 hours again. A still more complex form having around 20 GUI elements with several business rules and data validation would probably take a lot more time. In such a case, try to separate out sets of GUI elements and functionality so that each part appears to be similar in scope to the simple registration form. Then, add up the number of simple registration forms that you have derived out of the complex form, multiply it by the number of man-hours per simple registration form, and presto, you've got the number of man-hours to develop the complex registration form.

The same concept can be applied to business objects whose functionality is complex. The objects should be simplified into simple objects for which effort can be more easily determined. When developing a common event-handling component for the application, try to first break it down into easier to understand 'pieces'. Assuming that event handling component would involve logging certain type of events and excludes event fired on the presentation tier and database tier. Logging should be a separate component to be developed as it may also involve exception logging, security logging, performance logging, disk usage logging, C.P.U. logging etc. So, take out the logging component development when estimating the event object (it only uses the logging component). Now, the event object would involve defining events to be handled, data if any to be passed by the event, and developing event handlers for those events. Slowly, you will find that it is easier to figure out the effort involved to develop this component.

This is an easy to create, graphical view of the application and would make it easier to understand the scope of the application. Document all the details like the purpose, role, and location of objects in the object hierarchy tree. Other documents like use cases, activity diagrams, business requirements and workflows can be used to justify the objects in the tree. This tree is not a replacement for a full-fledged and approved design. It is just useful to get the ball rolling early in the project, and can be a forerunner to a complete design. Separate object hierarchy trees should be created to identify business objects, framework objects and presentation layer objects (form objects).

Do not forget the risks.

Another factor to consider in estimation is risk. Risk factors should be determined for the scope of the project, requirements, design & strategy, technology, processes (for development, payment, change mgmt, risk mgmt, and closing the project), and terms/conditions of the project. When all the stakeholders (at both client and development company) have understood and are comfortable with all the entire project, risk factors are low. Otherwise, the risk factors increase, and that too exponentially. Always try to determine and accept the risks including possible ones, at least within the core team. If everyone keeps portraying a rosy picture all the time just to look confident and positive then the project could end up badly. Identify the risks and identify how you are going to solve them, do not brush them aside. Each phase, stage, component should be classified based upon their risk factor. If the risk factor is too high, i.e., there are too many issues to resolve, you can be sure that the project will end up badly, and so best not get into it, unless maybe you need the (bitter) experience for whatever reasons.

Risks have to be classified by the development companies based upon their own experiences and priorities. Some ways to rate risks are suggested below:

Risk factors are rated high when most of the stakeholders have concerns. Even if one important feature of a project appears too difficult to execute, the risk is high. Issues like acceptable type of bugs and number of bugs for user acceptance, terms for closing the project, payments not being clear or misunderstood, make the project highly risky.

Risks are rated medium when a very small number of stakeholders have a few concerns. For example, the development team may not have very advanced knowledge of the technology but could provide some work around. Another could be that the customer's people cannot finalize a few unimportant workflows.

Risks are low when issues like the format of the forms are not finalized but the functionality is thoroughly understood and solutions approved.

Iterative development may always have a medium to high risk, as changes to existing modules are common feature here. Unless the stakeholders have clearly spelt out guidelines to solve change requirements and a good change management process, the risks here are often very high.

Waterfall methods are too rigid but have a lower risk factor. Here, feature changes usually mean extra costs to the customer, and inability to deliver features as per the contract spells higher penalties to the development company. But, the advantage here is that requirements are fixed upfront before making any commitments.

It's still weird machacha

Software estimation is too vague a subject to explain to the non-initiated. But then somebody's got to do it. Practice by estimating simple modules using the suggestions given in this article. Start with a login or simple registration form, and work your way into more complex forms. And record your reasons for the man-hours you estimate for a task. Sooner or later, you will cross the threshold and become a value for money estimator.

With suggestions from my readers, I may be able to add more value to this article.

A sample abstract for a software project

Software Project Estimate

Abstract

S.N.

Item

Unit

Qty

Role/Skill

Man days

Rate (INR)

Amount (INR)

Remarks

1

Visionary doc

Nos

1

n/a

2

4,000 .00

8,000.00

2

Workflows / Subworkflows

Nos

55

n/a

55

4,000 .00

220,000.00

3

Use cases

Nos

50

n/a

250

3,200 .00

800,000.00

4

Objects in hierarchy tree

Nos

210

n/a

262.5

3,200 .00

840,000.00

5

Technology

Nos

10

n/a

5

4,700 .00

23,500.00

gathering +analysis

6

Non-functional req doc

Nos

1

n/a

2

4,000 .00

8,000.00

7

Tiers

Nos

4

n/a

2

5,000 .00

10,000.00

8

Activity diagrams

Nos

100

n/a

1050

3,047 .62

3,200,000.00

9

Flowchart / Processes

Nos

100

n/a

800

3,000 .00

2,400, 000.00

10

Components

Nos

7

n/a

98

4,000 .00

392,000.00

11

Objects in framework tree

Nos

150

n/a

300

3,500 .00

1,050, 000.00

12

Deployment

Nos

2

n/a

22

3,181 .82

70,000.00

13

Test case designs

Nos

400

n/a

500

3,200 .00

1,600,000.00

14

Tools Requirement

Nos

6

n/a

3

5,000 .00

15,000.00

15

User Acceptance Testing

Nos

1

n/a

900

3,000 .00

2,700,000.00

total

4252

3,136 .89

13,336, 500.00

$296,366.67

Add Risk Factor

Nos

3

1.00

40,009, 500.00

$889,100.00

Requirements Gathering

S.N.

Item

Unit

Qty

Role/Skill

Man days /Unit

Rate

Amount

Remarks

1

Visionary doc

Nos

1

BA

2

4,000 .00

8,000.00

2

Workflows / Subworkflows

Nos

55

BA

1

4,000 .00

220,000.00

3

Use cases (major only)

Nos

50

BA

1

4,000 .00

200,000.00

user interface, user process components

4

Objects in hierarchy tree

Nos

210

Designer

0.25

4,000 .00

210,000.00

business components

5

Technology

Nos

3

BA

0.5

4,000 .00

6,000.00

IE, asp.net, sqlserver

6

Non-functional req doc

Nos

1

BA

2

4,000 .00

8,000.00

total

320

652,000.00

Requirement Analysis

S.N.

Item

Unit

Qty

Role/Skill

Man days /Unit

Rate

Amount

Remarks

1

Tiers

Nos

4

Architect

0.5

5,000 .00

10,000.00

presentation, business, data format, data storage

2

Activity diagrams

Nos

100

Designer

0.5

4,000 .00

200,000.00

3

Flowchart / Processes

Nos

100

Sr.Dev / Dev

1

3,000 .00

300,000.00

workflow components

4

Components

Nos

7

Architect / Designer

7

5,000 .00

245,000.00

interfaces, controller, data entities

5

Objects in framework tree

Nos

150

Designer

1

4,000 .00

600,000.00

service interfaces, data access, external interface, security

6

Technology

Nos

7

Architect

0.5

5,000 .00

17,500.00

html, xml, jscript, c#, asp.net, sql, com+,

7

Deployment

Nos

2

Architect

1

5,000 .00

10,000.00

design

8

Test case designs

Nos

400

Test lead

0.25

4,000 .00

400,000.00

9

Tools Requirement

Nos

6

Architect

0.5

5,000 .00

15,000.00

vs.net, load runner, win runner, nunit, vss, xml spy

total

776

12.25

1,797,500.00

Development and Testing Entities in Above Items

S.N.

Item

Unit

Qty

Role / Skill

Man days /Unit

Rate

Amount

Remarks

1

Flowchart / Processes

Nos

100

Sr.Dev / Dev

7

3,000 .00

2,100,000.00

Development of the workflow components

2

Activity diagrams

Nos

100

Sr.Dev / Dev

10

3,000 .00

3,000,000.00

Development of the workflow components other than those developed from the flowchart

These are the objects in the diagrams created and/or items identified in requirement gathering & analysis . The diagrams include the object hierarchy tree (framework, business objects, forms), work flows, flow charts, activity, use cases, components and deployment

History

This is the second cut.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Software development is an art, it can't be quantified, aproximated, or similar.I am talking here about true software, wich does not crahes ,missleads or complicates life more than it already is.In the same way a tree grows, an application should grow too - branch by branch, leaf by leaf, without planning each leaf or even each branch. It grows according to the environment it lives in, adapting each step of the way. Since you can't predict the environment, you can't say when it will be fully grown.
Think about Leonardo or any other genuine artist:what would have happend if someone would have hired him to do "Monalisa" in say, two weeeks?
Well -=nice dream=- but what about the money?
This is quite simple-there are Low risk investments and High risk investments-software is a high risk one. It is the bussinessman's job to take risks and programmer's job to build application(s); not the other way around.
Of course, if a genious programmer is also a sucessfull bussinessman than the hole software world goes to hell, fast....

In your article you made the assumption that all the coders would produce equal output, because you did not know how it can be estimated. However, there are empiricals which provide a better est based on language type used and experience of developer.

i assumed, for the sake of simplicity that all those involved in development can be taken as are equals in terms of effort and salary. and i have mentioned seperate roles, manhours and cost in the sample software estimate. in this article i was focussing on how to estimate a project without a design in place by using the documents created during requirements and analysis. at this stage it might not possible to exactly fix the number of people and their roles. again a company may have too many/little senior/junior developers for a given technology and so would normally use the available resources.

i am not aware of any empiricals to calculate manhours with roles. to my understanding (from my engineering knowledge) empiricals are based upon experience and not an exact mathematical derivation. (in some cases there were several empiricals to calculate the same thing and we could chose whichever we preferred based upon our experience ). please explain the empiricals you are talking about as this may help other readers (besides me ) and we could debate their importance.

thanks for your praises Shiva . this article focusses on how to estimate the man hours involved for developing a project and the rates mentioned here are arbitary. the final cost of the project/product would further depend upon the development company's business interest, market trends, govt. policies, competition from other companies/products and so on. as soon as i figure all that out i might try doing business for myself.

btw any venture capitalist out there wanna invest in developing a product for estimation based upon ideas mentioned here please get back to me .

I normally don't like to be critical about articles, but in my own opinion, this article looks like it is describing a shotgun approach to estimating a project - break the project into miniscule, ridiculous pieces and then over estimate everything. If the example given were to come across my desk as a project bid, it would be dismissed in five minutes.

There are several factors that seem to have been left out, or at lease glossed over, in your article. The biggest one deals with the risk assessment and handling critical risk factors.

You state that a high risk is where all stakeholders have an interest, and low risk is where few do. I have to disagree there, risk isn't based on who's looking at it, risk is based on complexity, availability and ability to complete a particular area, feature or task. For instance, a client may require that a particular report be placed in the system, obviously, since this is a requirement, the development firm also looks at this a necessary item, and the subcontractor that is hired to write it sees that this is an important item. Ok, by your analysis, this is a high risk item ... not so, becuase everyone (including the client) knows that writing a report is a simple matter, as they have already prototyped it to give an example. The development firm knows that the technology involved is already there, and finally the report sub contractor has done this many times and knows the tools that are needed are there. This really is a very low risk item.

A more realistic example of risk would be something along the lines of logging into a legacy mainframe system and pulling data some amount of data. The customer does it every day, they assumne it can all be done, but don't look at it as a high priority because its not in the package of results they want their new system to spit out. The developement firm sees this as a bit more of an involved item because they are not completely familiar with the old system. Now, the risk according to the article, would be medium or low, only the development firm really sees this as a risk factor. However, the development firm does not know with the proper interfaces are in place to allow the new system to access the old data, or for that matter, if the technology exists. Also, will new program modules need to be written on the old system to quickly get data out, and is the system so old that there are few to no progammers capable of writing those modules. The development firm also knows that if this data doesn't get pulled, then the end deliverable reports are going to be missing some critical information that will need to be retrieved some other way. So, now we have identified a potential project-stopping risk factor. This is an extremely high risk, and as another commentor stated, should be one of the first items researched and tackled in any development project - "rush to failure" I believe is the term sometimes used, minimize the project impact by determining failure and alternatives early.

Now, when you take into account the descriptiong of risk factor I have put forth, then factor in the risk description in the article (which, by the way is more aptly named 'perceived risk', slightly different) you have metric for the project estimate that helps to gauge portential failure and assist is client expectation management.

I've gone on about this enough, but a few of the other things that you failed to mention is that risk factors are always changing and need to be updated, for instance with the legacy system, once it is determined that the interface technology exists, and the data can be retrieved without additional programming (or additional programming and a subcontractor is found), then that risk factor obviously decreases -- and when that particular project area is complete, the risk is removed. Also, estimators should be familiar with development staff and capabilities, grossly over estimated project often come from estimators, business analysts and sales people who have no contact with the developers and have no clue as to what may already be in their own library arsenal.

yep this is a shotgun view of estimation. it could be read along with another one of my articles at the following address, http://www.codeproject.com/gen/design/Estimation.asp
(not that it is a better one either).
could you suggest some web sites where more info on estimation (and risk) can be found for the non-initiated.

i havent gotten too much into risk as i have a limited knowledge of the subject. i mentioned it only because it is an important factor that affects the cost of the project. risk estimation based upon specific modules/issues, done with a full fledged design is always a better option. my aim was to work out an estimate even without getting into the design.

BTW just fyi of all the readers, (so far) all the articles i have written here (so far) are not based upon info from other articles/websites/books. They are only my own views on the subject (refer sub title) based upon my limited experience.

Typically, estimates are generated for the purpose of deciding whether a project should start or continue.

I think it is vital, therefore, that each estimate detail line includes a percentage confidence factor.

I always break up projects (even little ones) into phases, tackling the highest (perceived) risk in the first phase. Confidence estimates usually get weaker for later phases which depend on the quality of results from the first phase(s).

Using this method I can present a realistic estimate with best and worst case values rather than an optimistic guess.