How to determine number of resources to be allocated in a software project?

Question

Last day I have been interviewed and the interviewer asked me as given the outline of a project, how can we determine the number of resources to be needed for the same?

I don't know to do so.

Is there any standard way of doing so? or is it based on the experience? Or how?

I am pretty new in this activity and my knowledge is zero at present .... so any clear explanation with some example(simple) will help me(and people like me) to understand this.

Answer 1

Any question you might get in an interview, try to answer it. There are many trick questions that are not there for the sake of the answer, but to test your adaptability to current situation. So never answer no, but at least take a considerate guess. One of those questions might be: how many gas stations do you think there are in USA - you get the point.

Back to your question - assuming that resources include people and necessary hw/sw, I would say that you first see what can you use - how many developers there are at your disposal, what are their strengths / weaknesses. You must based on experience try to guess how long the project would take with one average developer (and this is based only on your experience) and add as many developers you need to meet the deadline. Now, how will the project be organized (project manager, system architect, senior devs etc...) is dependent on the size of the project, and the development methodology you use (Scrum, XP ... ). You can have company - wide system architect that developed framework for most of your solutions. You can have something entirely else - and that's why I would say that this is really just a tricky question to see you adapt.

Back to the point of hw / sw -> this means you go and buy anything that can shorten the timespan of the project enough that it will exceed and return the money invested in those tools (faster computers, IDE, UI frameworks etc...)

Whatever the task, I would just say that finishing it is mostly dependent on not how many devs there are, but how many of those are proficient in the language / framework you are working on - so it is all down to the quality of the team.

Answer 2

Some steps that you can follow.

• Create the work break down structure and timeline of the project

• Get the developers' competency matrix and their unallocated time.

• Match the WBS and Developers in the matrix

• Assign developers accordingly.

Answer 3

This question is best answer by Mythical Man month

What it tells you is that there two catagory of tasks - a. partition-able and b. non-paritionable

As you add more people the partitionable work can be reduced in each step. However, the intercommunication costs grow worse for each addition, especially if each subtask must be separately coordinated with each other subtask the total permutation is ( n(n-1)/2 ) where n is a number of people.

If for a project (which is generally always the case) where communication effort dominates the reduction by parallelization is out weight by added complexity posed by required communication and hence adding more men after some point LENGTHENS, NOT SHORTENS, the schedule.

This is not to say put only 1 person for all projects but, there is an optimum point of people vs. Schedule.

There are various factors (also listed in book) but best optimization could be - for a typical 9 man month project you should have SQRT(9) people = 3.

Answer 4

This is a pretty deep topic with a lot of research in it. There's a book called Software Estimation: Demystifying the Black Art which I'm told is pretty good, though I have yet to read it myself.

As far as completion time and total man hours goes, evidence-based scheduling has given me a lot of success. Quoting myself from another answer:

Long story short, you split up the task, write down how long you think it'll take to complete each task (including interruptions like coffee breaks, bosses nagging you, StarCraft, etc.), and then time how long it actually takes you to complete some of those tasks. It's important to be blunt, and to include all your distractions -- because that's part of life as a developer, and it's a realistic factor that influences the time it takes to finish your work.

Then you can either multiply the average estimated-to-actual time against the estimated time of the remaining tasks, or you can take the error factor of your estimations to run a Monte Carlo simulation and determine the probability that you'll be done your tasks on any given date.

The end result is a graph that looks like the first one in that link, where the X axis is the finish date and the Y axis is the probability that it's finished:

I can't think of many other significant and measurable resources that'd be involved in software development, but if there are any, say, the cost in dollars of a web service used throughout development, you could probably apply this same technique with different variables to yield a satisfactory result.