Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

as a project manager or CTO how would I calculate the "time" it takes to develop a software system? For Example I would be responsible for developing a large web application in Java, MySQL, HTML, JSF. How do I correctly calculate how much time this takes?

Prerequisites: I do not know the team that will do this job (so I can not ask them how long they might need). I did not do any calculations like this before. I am completely new in this role. But I have some very basic/slight programming background...

Also any good resources (=links) or answers are very much appreciated.

share|improve this question
    
That's tough - but I'd read Pragmatic Programmer and learn more about team dynamics - amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/… –  Adel Sep 12 '11 at 2:02
3  
i have a large fishtank full of fish, all swimming in random directions. you can only see part of the tank for a few seconds, through a keyhole. How long will it take you to count the fish? –  Steven A. Lowe Sep 12 '11 at 3:30
add comment

4 Answers 4

up vote 3 down vote accepted

There are two general approaches, but most require a lot more information than you have right now. Without knowing more about the project and team, neither method can apply. Once you know more, you can either apply parametric estimation models, such as COCOMO II, size estimation methods such as function point analysis, proxy-based estimation, or team-based estimation techniques such as the Planning Game or wideband delphi.

Typically, before you begin estimating, you need at least a rough idea of the scope of the software project. This is usually done by starting to capture requirements in the form of a Software Requirements Specification, user stories, or some other technique. Establishing an overarching vision and scope for the project would also help as well.

Once you've established sufficient information about the project, you can begin the estimation process, depending on the methods that you choose. It might be advisable to even use multiple estimation methods. For example, using wideband delphi as a check for the output of COCOMO.

If you want to know more about software estimation, I would highly suggest reading Software Estimation: Demystifying the Black Art by Steve McConnell. He talks about many estimation topics and techniques and explains a number of best practices regardless of the size of the project. Also, for general project management topics, I would also suggest McConnell's Rapid Development: Taming Wild Software Schedules, where he talks about topics such as staffing, process management, and silver bullets.

share|improve this answer
    
thank, great, a lot of useful information for me to dig deeper. thanks very much!! –  Jens Sep 13 '11 at 0:21
add comment

You can't. We can't either. We can give you a rough guess, but that's all it will ever be - and it requires quite a bit of expertise to give you that, too.

You should first find a developer, then ask them fro a price estimate, then consider whether or not this price is good for you. If the project is big it might take a few days to do the estimate - in which case the developer may charge you for estimating the price.

share|improve this answer
add comment

Estimation is complex for seasoned professionals. Especially that the project is big. I suggest you finish the essential requirements phase and by then, sit with your senior programmer to identify the tasks and ask him for his input into this using some of what Thomas Owens suggested above.

You need to be aware that the estimate may have to be revised as the project progresses and as new team members start producing deliverables.

There are many variables that could go into a software project such as: People skills, number of people, development methodology, delivery methodology, customer cooperation, training time, utility software problems, back-end system interfaces, requirements stability, team communication, etc.

A warning note, the risk in your case is high.

share|improve this answer
    
+1 for the warning note. –  HLGEM Sep 12 '11 at 13:52
add comment

The trouble is, you're asking a question that doesn't have a well defined answer. It's a function of the team, the technology choices (which you need to allow the team to make, don't specify them up front), and, most important of all, how often your business requirements change.

I think first of all you need to find yourself a lead developer and/or scrum master (or some other agile development expert), and get them to start the estimation process off. That will get you an idea of how long it will be (and therefore how much it will cost) to get to something minimally useful. From there you just prioritize features regularly, and they arrive within a fairly short time... but first you need that initial start.

Oh, and the estimate will depend on certain assumptions. Do not change those assumptions without getting the estimate re-done, as that can make a really large difference.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.