Estimating ASP.NET Software Development Task Time

**Ken Dopierala Jr.** · Jul 21 '05, 06:47 PM

Re: Estimating ASP.NET Software Development Task Time

Hi,

The best thing is to have experience and also know the skill level of your
team with both ASP.Net and VB.Net. If you've coded the tasks before (or if
you've been a team lead before) then using your past experience will help.
If you've only coded before then talk to the developers you now lead to
guage their skill level. If you've neither coded in .Net or been a team
lead before then enjoy the paycheck and dole out your responsibilitie s to
one of your developers. Have them report to you and try to understand the
terminology they are using with you, or at the very least memorize it. If
it is confusing to you then it will probably be confusing to the people you
report to which means you can regurgitate this terminology to them and
hopefully hold onto your job. Keep your lead developers happy and never let
on about what you don't know. Just write it down and while they are
performing your responsibilitie s bust your butt to investigate and do that
dreaded "reading" thing and try to learn.

As lead this is what you should be doing:

1. Find out if ASP.Net and VB.Net are the tools you need to finish the
project.
2. Define your layers: UI, Data Access, Business Logic, and etc.
3. Use visio or pen and paper to create the prototypes of all objects.
4. Break your project down into a series of tasks for each of the layers.
5. Create milestones at which time the current version goes to QA.
6. Create a document and submit it to your boss(es). Make sure you let
them know that a change in architecture and agressive QA can offset
milestones.
7. Get the project approved and then get it finished.

Good luck! Ken.

--
Ken Dopierala Jr.
For great ASP.Net web hosting try:

Cloudflare Captcha Page

http://www.webhost4life.com/default.asp?refid=Spinlight

If you sign up under me and need help, email me.

"sympatico" <feedback@a1vbc ode.com> wrote in message
news:O8zkd.2537 2$km5.1383979@n ews20.bellgloba l.com...[color=blue]
> I am looking for a good document of spread sheet that can help me better
> estimate the amount of time and money a software development project[/color]
should[color=blue]
> take. I am using .NET Framework I have been given the responsibility as[/color]
team[color=blue]
> lead to give estimates on a series of projects my team will be given. I am
> wondering without reading spending alot of time reading books is there
> something on the web now either a tool or a formal i can use as a bases to
> increase the accuracy of estimate the amount of time it will take to built
> ASP.NET application using VB.NET
>
>[/color]

**John Saunders** · Jul 21 '05, 06:48 PM

Re: Estimating ASP.NET Software Development Task Time

"Ken Dopierala Jr." <kdopierala2@wi .rr.com> wrote in message
news:ebenEO5xEH A.2656@TK2MSFTN GP14.phx.gbl...[color=blue]
> Hi,
>
> The best thing is to have experience and also know the skill level of your
> team with both ASP.Net and VB.Net. If you've coded the tasks before (or
> if
> you've been a team lead before) then using your past experience will help.
> If you've only coded before then talk to the developers you now lead to
> guage their skill level. If you've neither coded in .Net or been a team
> lead before then enjoy the paycheck and dole out your responsibilitie s to
> one of your developers. Have them report to you and try to understand the
> terminology they are using with you, or at the very least memorize it. If
> it is confusing to you then it will probably be confusing to the people
> you
> report to which means you can regurgitate this terminology to them and
> hopefully hold onto your job. Keep your lead developers happy and never
> let
> on about what you don't know. Just write it down and while they are
> performing your responsibilitie s bust your butt to investigate and do that
> dreaded "reading" thing and try to learn.
>
> As lead this is what you should be doing:
>
> 1. Find out if ASP.Net and VB.Net are the tools you need to finish the
> project.
> 2. Define your layers: UI, Data Access, Business Logic, and etc.
> 3. Use visio or pen and paper to create the prototypes of all objects.
> 4. Break your project down into a series of tasks for each of the layers.
> 5. Create milestones at which time the current version goes to QA.
> 6. Create a document and submit it to your boss(es). Make sure you let
> them know that a change in architecture and agressive QA can offset
> milestones.
> 7. Get the project approved and then get it finished.[/color]

8. Learn from the successes and failures of the project and use those
lessons next time around. In particular, try to learn from the outcome of
each milestone, and try to make the milestones small enough to learn from.

Good luck. I've never heard of anyone being successful at estimating
projects based on spreadsheets and documents. I've also never had the
pleasure of working in an environment where projects take the amount of time
and money that they "should take".

But then again, I've always been cynical about metrics. I don't think humans
are very good at estimating human error. It may be a better idea to reduce
the amount possible human error rather than trying to estimate the amount.
Good Software Engineering practices can help with this - things like design
and code reviews, unit, integration and regression testing, nightly builds
followed by test runs, good source control and bug tracking, and tying bugs
back into the testing cycle.

If your processes reduce the number of errors, that may make your estimates
more accurate.

John Saunders

Estimating ASP.NET Software Development Task Time

Estimating ASP.NET Software Development Task Time

Comment

Comment