Re: [OT] Estimating a Struts-based project

2003-03-25 Thread Alexandre Jaquet
for my project I've done from 29 february  till now : 

- 35 view in swing  
- 12 struts view 
~ 100 class
-11 500 lines of code
-done a complete db schema 28 tables
-8 free days
-all the stuff as been tested

must be finish on 5 may :
+ 10 views in swing
+ 6 view with struts
+ finish all the architecture doc

But 5 month of analysis before. 
I'm not sure if I'm slow for a student ?

--
Alexandre Jaquet

- Original Message - 
From: "Chappell, Simon P" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Tuesday, March 25, 2003 5:59 PM
Subject: RE: [OT] Estimating a Struts-based project


Hmmm. I'll see what I can scrounge up from the QA reject bin.

>-Original Message-
>From: Nelson, Laird [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, March 25, 2003 10:57 AM
>To: 'Struts Users Mailing List'
>Subject: RE: [OT] Estimating a Struts-based project
>
>
>> -Original Message-
>> From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
>> Different section of IS. The area that I'm in is responsible 
>> for distribution operations, so we'll schedule, pick, pack 
>> and ship your customised LE suit to you, but the Internet 
>> group will actually take your order. :-)
>
>So the trick is to talk directly to you guys, and then my suit is free,
>right?  BTW, I take a 39R.
>
>Cheers,
>Laird
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Nelson, Laird
> -Original Message-
> From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
> Hmmm. I'll see what I can scrounge up from the QA reject bin.

As long as it can be customized.  Extensively.

Cheers,
Laird

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Chappell, Simon P
Hmmm. I'll see what I can scrounge up from the QA reject bin.

>-Original Message-
>From: Nelson, Laird [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, March 25, 2003 10:57 AM
>To: 'Struts Users Mailing List'
>Subject: RE: [OT] Estimating a Struts-based project
>
>
>> -Original Message-
>> From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
>> Different section of IS. The area that I'm in is responsible 
>> for distribution operations, so we'll schedule, pick, pack 
>> and ship your customised LE suit to you, but the Internet 
>> group will actually take your order. :-)
>
>So the trick is to talk directly to you guys, and then my suit is free,
>right?  BTW, I take a 39R.
>
>Cheers,
>Laird
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Chappell, Simon P
No. There's plenty of work, enough that LE is accepting resumes from developers. In 
fact, it's the large volume of work that is causing some of the smaller "nice to have" 
projects to be pushed to the back-burners for now, while the big strategic stuff gets 
time front and centre.

>-Original Message-
>From: Jeff Kyser [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, March 25, 2003 10:50 AM
>To: Struts Users Mailing List
>Subject: Re: [OT] Estimating a Struts-based project
>
>
>Sounds like its time for a new tag:
>
>   
>
>:^)
>
>-jeff
>
>On Tuesday, March 25, 2003, at 10:39  AM, Chappell, Simon P wrote:
>
>> You guys are wicked! I was trying to be serious (for a change).
>>
>> Interestingly enough, the 768hr estimate that was in my 
>original post 
>> (and that I was worried was too low) has killed the project. The 
>> resource manager took one look at it and is not even planning to 
>> submit it for scheduling.
>>
>> Simon
>>
>>> -Original Message-
>>> From: Andrew Hill [mailto:[EMAIL PROTECTED]
>>> Sent: Tuesday, March 25, 2003 10:37 AM
>>> To: Struts
>>> Subject: [OT] Estimating a Struts-based project
>>>
>>>
>>> btw: be sure you have a scrabble set handy in case they want
>>> to see how you
>>> calculated it... :-)
>>>
>>> -Original Message-
>>> From: Andrew Hill [mailto:[EMAIL PROTECTED]
>>> Sent: Wednesday, 26 March 2003 00:36
>>> To: Struts Users Mailing List
>>> Subject: RE: [OT] Estimating a Struts-based project
>>>
>>>
>>> hmm. Then there is but one estimate you can give...
>>>
>>> 42!
>>>
>>> If they ask whether thats days or hours tell them it doesnt
>>> really make a
>>> difference... ;-)
>>>
>>> -Original Message-
>>> From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
>>> Sent: Wednesday, 26 March 2003 00:33
>>> To: Struts Users Mailing List
>>> Subject: RE: [OT] Estimating a Struts-based project
>>>
>>>
>>> For our initial estimate, we do not have the luxury of
>>> use-cases. Hence the
>>> need to generate an estimate based on the smallest quantity of
>>> known data
>>> possible.
>>>
>>>> -Original Message-
>>>> From: Mehra, Vishal [mailto:[EMAIL PROTECTED]
>>>> Sent: Tuesday, March 25, 2003 10:05 AM
>>>> To: 'Struts Users Mailing List'
>>>> Subject: RE: [OT] Estimating a Struts-based project
>>>>
>>>>
>>>> I would break these down to use cases and assign complexity to
>>>> each one of
>>>> them and then try estimating it that way.
>>>>
>>>> Regards,
>>>> Vishal.
>>>>
>>>>
>>>> -Original Message-
>>>> From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
>>>> Sent: Monday, March 24, 2003 11:14 AM
>>>> To: Struts Mailing List (E-mail)
>>>> Subject: [OT] Estimating a Struts-based project
>>>>
>>>>
>>>> I have just completed an initial estimate for a Struts-based web
>>>> application. I am curious as to what estimation methods folks
>>>> out there use
>>>> for their initial estimates. The revised estimate will be
>>>> delivered after
>>>> more analysis is performed.
>>>>
>>>> I am fed up with making wild guesses for initial estimates and
>>>> wondered if
>>>> there was any way to take the small amount of information
>>>> available up front
>>>> (i.e. the number of screens on the user's initial workflow
>>> requirements
>>>> document) and extrapolate it into an estimate. I understand
>>>> that the margin
>>>> of error is gonna be big and hairy on this puppy, but it's 
>an initial
>>>> estimate created with a dearth of information, so what do you
>>>> expect? :-)
>>>>
>>>> What I did was:
>>>>
>>>> Take the estimated number of application screens: s=13
>>>> Take the number of application user roles: r=3
>>>> Figure which screens are used by which roles and total: sr=32
>>>> Estimate the
>>>> number of actions: a = sr * 2 = 64 Application units of work:
>>>> auow = a + sr
>>>> = 96 Total units of work (including admin screens): tuow =
>>>> auow * 2 = 192
>

RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Nelson, Laird
> -Original Message-
> From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
> Different section of IS. The area that I'm in is responsible 
> for distribution operations, so we'll schedule, pick, pack 
> and ship your customised LE suit to you, but the Internet 
> group will actually take your order. :-)

So the trick is to talk directly to you guys, and then my suit is free,
right?  BTW, I take a 39R.

Cheers,
Laird

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [OT] Estimating a Struts-based project

2003-03-25 Thread Jeff Kyser
Sounds like its time for a new tag:

	

:^)

-jeff

On Tuesday, March 25, 2003, at 10:39  AM, Chappell, Simon P wrote:

You guys are wicked! I was trying to be serious (for a change).

Interestingly enough, the 768hr estimate that was in my original post 
(and that I was worried was too low) has killed the project. The 
resource manager took one look at it and is not even planning to 
submit it for scheduling.

Simon

-Original Message-
From: Andrew Hill [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 25, 2003 10:37 AM
To: Struts
Subject: [OT] Estimating a Struts-based project
btw: be sure you have a scrabble set handy in case they want
to see how you
calculated it... :-)
-Original Message-
From: Andrew Hill [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 26 March 2003 00:36
To: Struts Users Mailing List
Subject: RE: [OT] Estimating a Struts-based project
hmm. Then there is but one estimate you can give...

42!

If they ask whether thats days or hours tell them it doesnt
really make a
difference... ;-)
-Original Message-
From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 26 March 2003 00:33
To: Struts Users Mailing List
Subject: RE: [OT] Estimating a Struts-based project
For our initial estimate, we do not have the luxury of
use-cases. Hence the
need to generate an estimate based on the smallest quantity of
known data
possible.
-Original Message-
From: Mehra, Vishal [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 25, 2003 10:05 AM
To: 'Struts Users Mailing List'
Subject: RE: [OT] Estimating a Struts-based project
I would break these down to use cases and assign complexity to
each one of
them and then try estimating it that way.
Regards,
Vishal.
-Original Message-
From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2003 11:14 AM
To: Struts Mailing List (E-mail)
Subject: [OT] Estimating a Struts-based project
I have just completed an initial estimate for a Struts-based web
application. I am curious as to what estimation methods folks
out there use
for their initial estimates. The revised estimate will be
delivered after
more analysis is performed.
I am fed up with making wild guesses for initial estimates and
wondered if
there was any way to take the small amount of information
available up front
(i.e. the number of screens on the user's initial workflow
requirements
document) and extrapolate it into an estimate. I understand
that the margin
of error is gonna be big and hairy on this puppy, but it's an initial
estimate created with a dearth of information, so what do you
expect? :-)
What I did was:

Take the estimated number of application screens: s=13
Take the number of application user roles: r=3
Figure which screens are used by which roles and total: sr=32
Estimate the
number of actions: a = sr * 2 = 64 Application units of work:
auow = a + sr
= 96 Total units of work (including admin screens): tuow =
auow * 2 = 192
Estimate an effort factor per unit: ef = 4hr Programmer work:
pw = tuow * ef
= 768hrs
Some assumptions included in these calculations include:
1. An average of two actions per screen role.
2. The administration facility of an application is about 50%
of the work.
3. The effort factor is a figure arrived at from knowledge of
the programmer
being tasked and the number of new technologies within the project.
Your thoughts please.

Simon

-
Simon P. Chappell [EMAIL PROTECTED]
Java Programming Specialist  www.landsend.com
Lands' End, Inc.   (608) 935-4526
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Chappell, Simon P

>So no customizemylandsendsuit.com?

Different section of IS. The area that I'm in is responsible for distribution 
operations, so we'll schedule, pick, pack and ship your customised LE suit to you, but 
the Internet group will actually take your order. :-)

>Cheers,
>Laird

Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Nelson, Laird
> -Original Message-
> From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
> Interestingly enough, the 768hr estimate that was in my 
> original post (and that I was worried was too low) has killed 
> the project. The resource manager took one look at it and is 
> not even planning to submit it for scheduling.

So no customizemylandsendsuit.com?

Cheers,
Laird

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Michael Mattox
> Interestingly enough, the 768hr estimate that was in my original
> post (and that I was worried was too low) has killed the project.
> The resource manager took one look at it and is not even planning
> to submit it for scheduling.

That's why it's important to be as accurate as possible, best that the
project be canceled now than half way through.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Chappell, Simon P
You guys are wicked! I was trying to be serious (for a change).

Interestingly enough, the 768hr estimate that was in my original post (and that I was 
worried was too low) has killed the project. The resource manager took one look at it 
and is not even planning to submit it for scheduling.

Simon

>-Original Message-
>From: Andrew Hill [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, March 25, 2003 10:37 AM
>To: Struts
>Subject: [OT] Estimating a Struts-based project
>
>
>btw: be sure you have a scrabble set handy in case they want 
>to see how you
>calculated it... :-)
>
>-Original Message-
>From: Andrew Hill [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, 26 March 2003 00:36
>To: Struts Users Mailing List
>Subject: RE: [OT] Estimating a Struts-based project
>
>
>hmm. Then there is but one estimate you can give...
>
>42!
>
>If they ask whether thats days or hours tell them it doesnt 
>really make a
>difference... ;-)
>
>-Original Message-
>From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, 26 March 2003 00:33
>To: Struts Users Mailing List
>Subject: RE: [OT] Estimating a Struts-based project
>
>
>For our initial estimate, we do not have the luxury of 
>use-cases. Hence the
>need to generate an estimate based on the smallest quantity of 
>known data
>possible.
>
>>-Original Message-
>>From: Mehra, Vishal [mailto:[EMAIL PROTECTED]
>>Sent: Tuesday, March 25, 2003 10:05 AM
>>To: 'Struts Users Mailing List'
>>Subject: RE: [OT] Estimating a Struts-based project
>>
>>
>>I would break these down to use cases and assign complexity to
>>each one of
>>them and then try estimating it that way.
>>
>>Regards,
>>Vishal.
>>
>>
>>-Original Message-
>>From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
>>Sent: Monday, March 24, 2003 11:14 AM
>>To: Struts Mailing List (E-mail)
>>Subject: [OT] Estimating a Struts-based project
>>
>>
>>I have just completed an initial estimate for a Struts-based web
>>application. I am curious as to what estimation methods folks
>>out there use
>>for their initial estimates. The revised estimate will be
>>delivered after
>>more analysis is performed.
>>
>>I am fed up with making wild guesses for initial estimates and
>>wondered if
>>there was any way to take the small amount of information
>>available up front
>>(i.e. the number of screens on the user's initial workflow 
>requirements
>>document) and extrapolate it into an estimate. I understand
>>that the margin
>>of error is gonna be big and hairy on this puppy, but it's an initial
>>estimate created with a dearth of information, so what do you
>>expect? :-)
>>
>>What I did was:
>>
>>Take the estimated number of application screens: s=13
>>Take the number of application user roles: r=3
>>Figure which screens are used by which roles and total: sr=32
>>Estimate the
>>number of actions: a = sr * 2 = 64 Application units of work:
>>auow = a + sr
>>= 96 Total units of work (including admin screens): tuow =
>>auow * 2 = 192
>>Estimate an effort factor per unit: ef = 4hr Programmer work:
>>pw = tuow * ef
>>= 768hrs
>>
>>Some assumptions included in these calculations include:
>>1. An average of two actions per screen role.
>>2. The administration facility of an application is about 50%
>>of the work.
>>3. The effort factor is a figure arrived at from knowledge of
>>the programmer
>>being tasked and the number of new technologies within the project.
>>
>>Your thoughts please.
>>
>>Simon
>>
>>-
>>Simon P. Chappell [EMAIL PROTECTED]
>>Java Programming Specialist  www.landsend.com
>>Lands' End, Inc.   (608) 935-4526
>>
>>-
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>-
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Michael Mattox
Come on Andrew, 42 is much too high.  Can't you trim that down a bit?

> -Original Message-
> From: Andrew Hill [mailto:[EMAIL PROTECTED]
> Sent: mardi 25 mars 2003 17:36
> To: Struts Users Mailing List
> Subject: RE: [OT] Estimating a Struts-based project
> 
> 
> hmm. Then there is but one estimate you can give...
> 
> 42!
> 
> If they ask whether thats days or hours tell them it doesnt really make a
> difference... ;-)
> 
> -Original Message-
> From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 26 March 2003 00:33
> To: Struts Users Mailing List
> Subject: RE: [OT] Estimating a Struts-based project
> 
> 
> For our initial estimate, we do not have the luxury of use-cases. 
> Hence the
> need to generate an estimate based on the smallest quantity of known data
> possible.
> 
> >-Original Message-
> >From: Mehra, Vishal [mailto:[EMAIL PROTECTED]
> >Sent: Tuesday, March 25, 2003 10:05 AM
> >To: 'Struts Users Mailing List'
> >Subject: RE: [OT] Estimating a Struts-based project
> >
> >
> >I would break these down to use cases and assign complexity to
> >each one of
> >them and then try estimating it that way.
> >
> >Regards,
> >Vishal.
> >
> >
> >-Original Message-
> >From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
> >Sent: Monday, March 24, 2003 11:14 AM
> >To: Struts Mailing List (E-mail)
> >Subject: [OT] Estimating a Struts-based project
> >
> >
> >I have just completed an initial estimate for a Struts-based web
> >application. I am curious as to what estimation methods folks
> >out there use
> >for their initial estimates. The revised estimate will be
> >delivered after
> >more analysis is performed.
> >
> >I am fed up with making wild guesses for initial estimates and
> >wondered if
> >there was any way to take the small amount of information
> >available up front
> >(i.e. the number of screens on the user's initial workflow requirements
> >document) and extrapolate it into an estimate. I understand
> >that the margin
> >of error is gonna be big and hairy on this puppy, but it's an initial
> >estimate created with a dearth of information, so what do you
> >expect? :-)
> >
> >What I did was:
> >
> >Take the estimated number of application screens: s=13
> >Take the number of application user roles: r=3
> >Figure which screens are used by which roles and total: sr=32
> >Estimate the
> >number of actions: a = sr * 2 = 64 Application units of work:
> >auow = a + sr
> >= 96 Total units of work (including admin screens): tuow =
> >auow * 2 = 192
> >Estimate an effort factor per unit: ef = 4hr Programmer work:
> >pw = tuow * ef
> >= 768hrs
> >
> >Some assumptions included in these calculations include:
> >1. An average of two actions per screen role.
> >2. The administration facility of an application is about 50%
> >of the work.
> >3. The effort factor is a figure arrived at from knowledge of
> >the programmer
> >being tasked and the number of new technologies within the project.
> >
> >Your thoughts please.
> >
> >Simon
> >
> >-
> >Simon P. Chappell [EMAIL PROTECTED]
> >Java Programming Specialist  www.landsend.com
> >Lands' End, Inc.   (608) 935-4526
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Andrew Hill
hmm. Then there is but one estimate you can give...

42!

If they ask whether thats days or hours tell them it doesnt really make a
difference... ;-)

-Original Message-
From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 26 March 2003 00:33
To: Struts Users Mailing List
Subject: RE: [OT] Estimating a Struts-based project


For our initial estimate, we do not have the luxury of use-cases. Hence the
need to generate an estimate based on the smallest quantity of known data
possible.

>-Original Message-
>From: Mehra, Vishal [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, March 25, 2003 10:05 AM
>To: 'Struts Users Mailing List'
>Subject: RE: [OT] Estimating a Struts-based project
>
>
>I would break these down to use cases and assign complexity to
>each one of
>them and then try estimating it that way.
>
>Regards,
>Vishal.
>
>
>-Original Message-
>From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
>Sent: Monday, March 24, 2003 11:14 AM
>To: Struts Mailing List (E-mail)
>Subject: [OT] Estimating a Struts-based project
>
>
>I have just completed an initial estimate for a Struts-based web
>application. I am curious as to what estimation methods folks
>out there use
>for their initial estimates. The revised estimate will be
>delivered after
>more analysis is performed.
>
>I am fed up with making wild guesses for initial estimates and
>wondered if
>there was any way to take the small amount of information
>available up front
>(i.e. the number of screens on the user's initial workflow requirements
>document) and extrapolate it into an estimate. I understand
>that the margin
>of error is gonna be big and hairy on this puppy, but it's an initial
>estimate created with a dearth of information, so what do you
>expect? :-)
>
>What I did was:
>
>Take the estimated number of application screens: s=13
>Take the number of application user roles: r=3
>Figure which screens are used by which roles and total: sr=32
>Estimate the
>number of actions: a = sr * 2 = 64 Application units of work:
>auow = a + sr
>= 96 Total units of work (including admin screens): tuow =
>auow * 2 = 192
>Estimate an effort factor per unit: ef = 4hr Programmer work:
>pw = tuow * ef
>= 768hrs
>
>Some assumptions included in these calculations include:
>1. An average of two actions per screen role.
>2. The administration facility of an application is about 50%
>of the work.
>3. The effort factor is a figure arrived at from knowledge of
>the programmer
>being tasked and the number of new technologies within the project.
>
>Your thoughts please.
>
>Simon
>
>-
>Simon P. Chappell [EMAIL PROTECTED]
>Java Programming Specialist  www.landsend.com
>Lands' End, Inc.   (608) 935-4526
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Chappell, Simon P
For our initial estimate, we do not have the luxury of use-cases. Hence the need to 
generate an estimate based on the smallest quantity of known data possible.

>-Original Message-
>From: Mehra, Vishal [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, March 25, 2003 10:05 AM
>To: 'Struts Users Mailing List'
>Subject: RE: [OT] Estimating a Struts-based project
>
>
>I would break these down to use cases and assign complexity to 
>each one of
>them and then try estimating it that way.
>
>Regards,
>Vishal.
>
>
>-Original Message-
>From: Chappell, Simon P [mailto:[EMAIL PROTECTED] 
>Sent: Monday, March 24, 2003 11:14 AM
>To: Struts Mailing List (E-mail)
>Subject: [OT] Estimating a Struts-based project
>
>
>I have just completed an initial estimate for a Struts-based web
>application. I am curious as to what estimation methods folks 
>out there use
>for their initial estimates. The revised estimate will be 
>delivered after
>more analysis is performed.
>
>I am fed up with making wild guesses for initial estimates and 
>wondered if
>there was any way to take the small amount of information 
>available up front
>(i.e. the number of screens on the user's initial workflow requirements
>document) and extrapolate it into an estimate. I understand 
>that the margin
>of error is gonna be big and hairy on this puppy, but it's an initial
>estimate created with a dearth of information, so what do you 
>expect? :-)
>
>What I did was:
>
>Take the estimated number of application screens: s=13
>Take the number of application user roles: r=3
>Figure which screens are used by which roles and total: sr=32 
>Estimate the
>number of actions: a = sr * 2 = 64 Application units of work: 
>auow = a + sr
>= 96 Total units of work (including admin screens): tuow = 
>auow * 2 = 192
>Estimate an effort factor per unit: ef = 4hr Programmer work: 
>pw = tuow * ef
>= 768hrs
>
>Some assumptions included in these calculations include:
>1. An average of two actions per screen role.
>2. The administration facility of an application is about 50% 
>of the work.
>3. The effort factor is a figure arrived at from knowledge of 
>the programmer
>being tasked and the number of new technologies within the project.
>
>Your thoughts please.
>
>Simon
>
>-
>Simon P. Chappell [EMAIL PROTECTED]
>Java Programming Specialist  www.landsend.com
>Lands' End, Inc.   (608) 935-4526
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Mehra, Vishal
I would break these down to use cases and assign complexity to each one of
them and then try estimating it that way.

Regards,
Vishal.


-Original Message-
From: Chappell, Simon P [mailto:[EMAIL PROTECTED] 
Sent: Monday, March 24, 2003 11:14 AM
To: Struts Mailing List (E-mail)
Subject: [OT] Estimating a Struts-based project


I have just completed an initial estimate for a Struts-based web
application. I am curious as to what estimation methods folks out there use
for their initial estimates. The revised estimate will be delivered after
more analysis is performed.

I am fed up with making wild guesses for initial estimates and wondered if
there was any way to take the small amount of information available up front
(i.e. the number of screens on the user's initial workflow requirements
document) and extrapolate it into an estimate. I understand that the margin
of error is gonna be big and hairy on this puppy, but it's an initial
estimate created with a dearth of information, so what do you expect? :-)

What I did was:

Take the estimated number of application screens: s=13
Take the number of application user roles: r=3
Figure which screens are used by which roles and total: sr=32 Estimate the
number of actions: a = sr * 2 = 64 Application units of work: auow = a + sr
= 96 Total units of work (including admin screens): tuow = auow * 2 = 192
Estimate an effort factor per unit: ef = 4hr Programmer work: pw = tuow * ef
= 768hrs

Some assumptions included in these calculations include:
1. An average of two actions per screen role.
2. The administration facility of an application is about 50% of the work.
3. The effort factor is a figure arrived at from knowledge of the programmer
being tasked and the number of new technologies within the project.

Your thoughts please.

Simon

-
Simon P. Chappell [EMAIL PROTECTED]
Java Programming Specialist  www.landsend.com
Lands' End, Inc.   (608) 935-4526

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Chappell, Simon P


>-Original Message-
>From: Michael Mattox [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, March 25, 2003 9:47 AM
>To: Struts Users Mailing List
>Subject: RE: [OT] Estimating a Struts-based project



>> >This sounds like a perfect scenario for eXtreme Programming.
>>
>> Actually, the first Struts project we did here, we used elements
>> of XP. It went well and was declared a huge success by the CEO at
>> the company employee meeting! :-)
>
>Glad to hear that!  I hope you can use even more XP principles 
>on your next
>project.

That's the plan. I'm trying to get more testing added in this time around. We used 
unit testing, but this time there will be more of that and I'm also looking to add in 
functional, performance and load testing to the mix.

>Michael

Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Chappell, Simon P

>-Original Message-
>From: Andrew Hill [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, March 25, 2003 9:00 AM
>To: Struts Users Mailing List
>Subject: RE: [OT] Estimating a Struts-based project
>
>
>Well given such constraints, your most accurate estimates are 
>likely to come
>from an astrologer - or even an economist - nah! thats going a 
>bit far. Ill
>stick with the astrologer.

:-)

>Failing that you could do what I do when subjected to the 
>gnashing of teeth
>routine.
>These estimates arent worth [one of Mark's this's] but the 
>proportions are
>correct - just not the magnitude:
>
>First you estimate the times using the method you think would 
>actually come
>up with something thats relatively accurate. This will of 
>course give you
>estimates that the client won't accept.

I'm very good at coming up with estimates that make them spit blood.

>The client of course already has their own 'estimate' (they call it a
>deadline).

Yes. Every project starts with an acronym and a deadline. Well known fact. Actually, 
that's the only well known thing at the start of most projects.

>You see how many hours there are until that 
>deadline, and then
>allocate your estimates to add up to that based on the 
>proportions in the
>'real' estimate.

So, don't bother creating an estimate. Or create one that you are happy to have 
ignored. This is why I want to algorithmise (not a real word) the process so that I 
can easily and with little real effort create a quasi-realistic estimate that 
management can then safely ignore, but that I could actually work from the 1% of the 
time that they supprise me and accept the estimate.

>Then think of something that sounds quite unlikely to occur 
>(but is in fact
>100% certain (an unexpected windows bug perhaps?)) and make a 
>small note on
>the quote that if this happens it just might possibily in the 
>worst case
>increase the estimates by a factor of x (where of course x is 
>the value that
>the clients estimate of total work needs to be multiplied with 
>to get the
>real estimate of total work...)

This is too much like CYA and I never do that. If a project fails after my estimate 
was ignored, I refuse to feel bad about it.

Simon

>-Original Message-
>From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, 25 March 2003 22:38
>To: Struts Users Mailing List
>Subject: RE: [OT] Estimating a Struts-based project
>
>
>These have all been good suggestions, but I am constrained 
>here by a number
>of factors.
>
>All our estimates have to be in hours.
>There is screaming and wailing and gnashing of teeth if the 
>estimate is "too
>big".
>We are not a software house, so the business gets to set schedules.
>We are a HIGHLY seasonal business, this forces many scheduling 
>decisions.
>etc. etc.
>
>Thanks to everyone.
>
>Simon
>
>-
>Simon P. Chappell [EMAIL PROTECTED]
>Java Programming Specialist  www.landsend.com
>Lands' End, Inc.   (608) 935-4526
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Michael Mattox
> >Hours are too fine grained.
>
> Agreed. But even when I give them estimates in days and weeks,
> they ask for them to be resubmitted in hours.

The XP approach uses "points" and velocity for scheduling.  The problem with
calendar time is then the managers expect the programmers to stick to the
dates.  But in reality no one can predict with absolute certainty how long a
project will take.  I think XP's approach handles this issue very nicely.

> >This sounds like a perfect scenario for eXtreme Programming.
>
> Actually, the first Struts project we did here, we used elements
> of XP. It went well and was declared a huge success by the CEO at
> the company employee meeting! :-)

Glad to hear that!  I hope you can use even more XP principles on your next
project.

Michael



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Chappell, Simon P

>-Original Message-
>From: Michael Mattox [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, March 25, 2003 9:03 AM
>To: Struts Users Mailing List
>Subject: RE: [OT] Estimating a Struts-based project
>
>
>> All our estimates have to be in hours.
>
>Hours are too fine grained.

Agreed. But even when I give them estimates in days and weeks, they ask for them to be 
resubmitted in hours.

>> There is screaming and wailing and gnashing of teeth if the 
>> estimate is "too
>> big".
>> We are not a software house, so the business gets to set schedules.
>> We are a HIGHLY seasonal business, this forces many 
>scheduling decisions.
>> etc. etc.
>
>This sounds like a perfect scenario for eXtreme Programming.  

Actually, the first Struts project we did here, we used elements of XP. It went well 
and was declared a huge success by the CEO at the company employee meeting! :-)

>Michael

Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Andrew Hill

"Nine women can't make a baby in a month"


True - but it could be amusing to watch them try ;-)


 Feel free to send them to my
email address to keep the list clutter-free.


On the contrary post them! Sure its a little off topic, but I think many
struts users, myself included, would be interested and could benefit. (Btw:
(ignoring my own vaguely semihumourous but otherwise useless contributions
for a moment) this is IMNSHO the sort of useful off-topic discussion that
makes the struts list much 'better' than more focused special interest
lists...)

-Original Message-
From: Nelson, Laird [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 25 March 2003 23:18
To: 'Struts Users Mailing List'
Subject: RE: [OT] Estimating a Struts-based project
Importance: Low


> -Original Message-
> From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
> There is screaming and wailing and gnashing of teeth if the
> estimate is "too big".

Long post follows, but I find this stuff interesting.  I'll shut up after
this.  :-)

I've found time estimate discussions are usually proxies for something else.

In right-side-scheduled projects, where the "right side" of the project
timeline is basically fixed, rationally or irrationally, when the project
leader is asking you for an estimate, she's usually asking you for a list of
things that can be cut from the scope (I'm not claiming this is a
revolutionary discovery).  The sooner you can get to *that* discussion, the
better the negotiation and management goes from there.  In pretty much every
time estimate discussion I've had, it's gone either like this:

Manager: Give me an estimate for the frobnicator piece.
Me: {various calculations} Three months.
Manager: Three MONTHS?  That's {however much it is} man hours!  That's too
long.  Can you do it in five weeks?  We need this project done by February.
Me: {honestly thinking} Well, I'm uncomfortable with five weeks;
realistically speaking, I could probably pull it off, but I wouldn't hav--
Manager: Well, what can we do to bring this thing in by February 17th?
[ding ding ding; turns out time estimate is not needed; switch to scope
discussion here]
Me: Hmm; how about trimming back the customizable frobnication interval?
That should knock some time off.

...or like this:

Manager: {looking sad and scared} OK, we signed a contract with BigCo last
week.  My hands are tied.  I have a wife and child to feed and I'm concerned
about my job.  We must deliver this project on May 12 or we all get fired.
How can we do this?
Me: {sympathetically sad and scared} Well, that means that {both of us stare
at project diagram with a big black vertical line on May 12} THIS piece has
to take four weeks, and THIS piece has to take three weeks...
{much playing with crayons or their sophisticated electronic equivalents
ensues; red lines and green milestones and burnt umber critical paths and so
forth are drawn and redrawn}
Both of us: There!  A diagram that shows that we can hit May 12!
Manager: Go.  Start coding.  I'll do what I can to find out what you need to
code.  Meanwhile I'll run this vaguely
insulting-to-me-because-it-reduces-my-job-to-drawing-pictures-to-support-som
ething-that-will-not-happen-as-methodically-as-presented diagram up to
senior management so they will continue to employ me.  And I will try not to
get in your way.
Me: OK; good luck.  I'll try to anticipate requirements and not get angry at
you because it's not really your fault either.
[dynamic scope negotiation occurs hereafter, often referred to as change
management, with varying levels of formality]

Sometimes you'll hear, "But it has to be done by September and we can't cut
*anything*.  Can't we just add more people?"  The old saw, "Nine women can't
make a baby in a month" usually helps here and adds a bit of humor to the
otherwise dreary process.  :-)

Incidentally, engineers (myself included) are at fault on the scope end as
much, oftentimes, as project managers or business types are on the time end:
we often claim that we can't trim scope because hey, that would cripple the
application, or, why bother even *releasing* the application if it can't do
this Great Trick?  Usually, I've found that if I swallow hard and dig in
hard enough I can find spots where scope can be cut.

There must be some educational reading out there for *real*-world project
management, where there *can't* be any deadline negotiation because (pick
one):

(a) the business folks have already started marketing the product
(b) a salesman doing his best to help the company has promised something to
a client by a certain date
(c) a multizillion-dollar contract has been signed with a date window as a
necessary condition
(d) a trade show featuring the product is coming up in June

I guess I'm talking about books 

RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Nelson, Laird
> -Original Message-
> From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
> There is screaming and wailing and gnashing of teeth if the 
> estimate is "too big".

Long post follows, but I find this stuff interesting.  I'll shut up after
this.  :-)

I've found time estimate discussions are usually proxies for something else.

In right-side-scheduled projects, where the "right side" of the project
timeline is basically fixed, rationally or irrationally, when the project
leader is asking you for an estimate, she's usually asking you for a list of
things that can be cut from the scope (I'm not claiming this is a
revolutionary discovery).  The sooner you can get to *that* discussion, the
better the negotiation and management goes from there.  In pretty much every
time estimate discussion I've had, it's gone either like this:

Manager: Give me an estimate for the frobnicator piece.
Me: {various calculations} Three months.
Manager: Three MONTHS?  That's {however much it is} man hours!  That's too
long.  Can you do it in five weeks?  We need this project done by February.
Me: {honestly thinking} Well, I'm uncomfortable with five weeks;
realistically speaking, I could probably pull it off, but I wouldn't hav--
Manager: Well, what can we do to bring this thing in by February 17th?
[ding ding ding; turns out time estimate is not needed; switch to scope
discussion here]
Me: Hmm; how about trimming back the customizable frobnication interval?
That should knock some time off.

...or like this:

Manager: {looking sad and scared} OK, we signed a contract with BigCo last
week.  My hands are tied.  I have a wife and child to feed and I'm concerned
about my job.  We must deliver this project on May 12 or we all get fired.
How can we do this?
Me: {sympathetically sad and scared} Well, that means that {both of us stare
at project diagram with a big black vertical line on May 12} THIS piece has
to take four weeks, and THIS piece has to take three weeks...
{much playing with crayons or their sophisticated electronic equivalents
ensues; red lines and green milestones and burnt umber critical paths and so
forth are drawn and redrawn}
Both of us: There!  A diagram that shows that we can hit May 12!
Manager: Go.  Start coding.  I'll do what I can to find out what you need to
code.  Meanwhile I'll run this vaguely
insulting-to-me-because-it-reduces-my-job-to-drawing-pictures-to-support-som
ething-that-will-not-happen-as-methodically-as-presented diagram up to
senior management so they will continue to employ me.  And I will try not to
get in your way.
Me: OK; good luck.  I'll try to anticipate requirements and not get angry at
you because it's not really your fault either.
[dynamic scope negotiation occurs hereafter, often referred to as change
management, with varying levels of formality]

Sometimes you'll hear, "But it has to be done by September and we can't cut
*anything*.  Can't we just add more people?"  The old saw, "Nine women can't
make a baby in a month" usually helps here and adds a bit of humor to the
otherwise dreary process.  :-)

Incidentally, engineers (myself included) are at fault on the scope end as
much, oftentimes, as project managers or business types are on the time end:
we often claim that we can't trim scope because hey, that would cripple the
application, or, why bother even *releasing* the application if it can't do
this Great Trick?  Usually, I've found that if I swallow hard and dig in
hard enough I can find spots where scope can be cut.

There must be some educational reading out there for *real*-world project
management, where there *can't* be any deadline negotiation because (pick
one):

(a) the business folks have already started marketing the product
(b) a salesman doing his best to help the company has promised something to
a client by a certain date
(c) a multizillion-dollar contract has been signed with a date window as a
necessary condition
(d) a trade show featuring the product is coming up in June

I guess I'm talking about books or links that do not tell you to iterate the
schedule (nice, desirable, rarely possible) or to plan in padding time
(absolutely impossible in nearly every case) to get around the issues.  Does
anyone know of books or links on this subject?  Feel free to send them to my
email address to keep the list clutter-free.

Cheers,
Laird

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Michael Mattox
> All our estimates have to be in hours.

Hours are too fine grained.

> There is screaming and wailing and gnashing of teeth if the 
> estimate is "too
> big".
> We are not a software house, so the business gets to set schedules.
> We are a HIGHLY seasonal business, this forces many scheduling decisions.
> etc. etc.

This sounds like a perfect scenario for eXtreme Programming.  

Michael



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Andrew Hill
Well given such constraints, your most accurate estimates are likely to come
from an astrologer - or even an economist - nah! thats going a bit far. Ill
stick with the astrologer.

Failing that you could do what I do when subjected to the gnashing of teeth
routine.
These estimates arent worth [one of Mark's this's] but the proportions are
correct - just not the magnitude:

First you estimate the times using the method you think would actually come
up with something thats relatively accurate. This will of course give you
estimates that the client won't accept.

The client of course already has their own 'estimate' (they call it a
deadline). You see how many hours there are until that deadline, and then
allocate your estimates to add up to that based on the proportions in the
'real' estimate.

Then think of something that sounds quite unlikely to occur (but is in fact
100% certain (an unexpected windows bug perhaps?)) and make a small note on
the quote that if this happens it just might possibily in the worst case
increase the estimates by a factor of x (where of course x is the value that
the clients estimate of total work needs to be multiplied with to get the
real estimate of total work...)

-Original Message-
From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 25 March 2003 22:38
To: Struts Users Mailing List
Subject: RE: [OT] Estimating a Struts-based project


These have all been good suggestions, but I am constrained here by a number
of factors.

All our estimates have to be in hours.
There is screaming and wailing and gnashing of teeth if the estimate is "too
big".
We are not a software house, so the business gets to set schedules.
We are a HIGHLY seasonal business, this forces many scheduling decisions.
etc. etc.

Thanks to everyone.

Simon

-
Simon P. Chappell [EMAIL PROTECTED]
Java Programming Specialist  www.landsend.com
Lands' End, Inc.   (608) 935-4526

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-25 Thread Chappell, Simon P
These have all been good suggestions, but I am constrained here by a number of factors.

All our estimates have to be in hours.
There is screaming and wailing and gnashing of teeth if the estimate is "too big".
We are not a software house, so the business gets to set schedules.
We are a HIGHLY seasonal business, this forces many scheduling decisions.
etc. etc.

Thanks to everyone.

Simon

-
Simon P. Chappell [EMAIL PROTECTED]
Java Programming Specialist  www.landsend.com
Lands' End, Inc.   (608) 935-4526

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [OT] Estimating a Struts-based project

2003-03-24 Thread Tim Shadel
Two other estimate tips:

1. Give your estimate using a range (preferably one that means something 
- e.g. soonest to latest around some likely date; you could get fancy 
and use standard deviations and ...)

2. Don't give overly precise estimates, for example
< 10 days, use days
< 6 weeks, use weeks
<= 5 months, use months
> 5 months && < 12 months, use quarters
Just some stuff from Steve McConnell's work and also the Pragmatic 
Programmers (I think, don't have references handy...).

--Tim

Jeff Smith wrote:
What? You don't increment the units as well?

If I am looking for a safe estimate and a developer tells me 2 weeks, I
automatically plan for 4 months. In all my years of experience I have NEVER
gone over estimate with this method and I have been only been over by more
than 20% 3 times in about 80 projects.
Sad but true.

Jefficus


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [OT] Estimating a Struts-based project

2003-03-24 Thread Jeff Smith
I did, I just worded it poorly. :-)

None of the projects ever came in late. And in all but 3 cases, the
overestimate was by less than 20%.

One has to be careful to clarify what I was estimating. This was usually
when asking a developer to estimate his effort to get a feature into a
shrink-wrapped (or other) commercial software product. The time includes all
design, prototyping and implementation time as well as all bug-fixing time
required on that feature to make it "ready for prime time". It also includes
programmers documentation and programmers contribution to product
documentation for that feature, as well as sick time and acts of God.

In other words, there are a lot of schedule costs that simply don't occur to
a developer when you ask for an estimate. And these little extra bits of
time add up to staggering project overruns if you aren't careful. Of course,
you also have to be careful with WHO you apply these estimate corrections
to. More senior developers probably factor many of these items into their
estimates. But if you're looking for a one-size-fits-all estimating rule, I
find this to be a handy upper-bound.

BTW, I have never had the courage to recommend that a 2 month project be
budgeted for 4 years, although there are times when I wish I had. :-)

Jefficus

- Original Message -
From: "David Graham" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 24, 2003 3:51 PM
Subject: Re: [OT] Estimating a Struts-based project


> But how close were your estimates?  You didn't say how far below the
> estimate you usually ended up.
>
> David
>
>
>
> >From: "Jeff Smith" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >Subject: Re: [OT] Estimating a Struts-based project
> >Date: Mon, 24 Mar 2003 15:47:27 -0700
> >
> >What? You don't increment the units as well?
> >
> >If I am looking for a safe estimate and a developer tells me 2 weeks, I
> >automatically plan for 4 months. In all my years of experience I have
NEVER
> >gone over estimate with this method and I have been only been over by
more
> >than 20% 3 times in about 80 projects.
> >
> >Sad but true.
> >
> >Jefficus
> >
> >- Original Message -
> >From: "Mark Galbreath" <[EMAIL PROTECTED]>
> >To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
> >Sent: Monday, March 24, 2003 10:31 AM
> >Subject: RE: [OT] Estimating a Struts-based project
> >
> >
> > > Okay, now double your estimate and you have a starting figure.
> > >
> > > -Original Message-
> > > From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, March 24, 2003 12:21 PM
> > > To: Struts Users Mailing List
> > > Subject: RE: [OT] Estimating a Struts-based project
> > >
> > >
> > >
> > >
> > > >-Original Message-
> > > >From: James Mitchell [mailto:[EMAIL PROTECTED]
> > > >Sent: Monday, March 24, 2003 11:18 AM
> > > >To: Struts Users Mailing List
> > > >Subject: Re: [OT] Estimating a Struts-based project
> > >
> > > 
> > >
> > > >Did you factor in the time for writing/maintaining tests?
> > >
> > > I'm hurt that you even felt you had to ask! ;-)
> > >
> > > Yes. As far as is possible, I have people write unit tests for code
> >(before
> > > if possible) and we are in the process of selecting further testing
> >tools
> > > for good stuff like functional testing, load testing and performance
> > > testing.
> > >
> > > Simon
> > >
> > > -
> > > Simon P. Chappell [EMAIL PROTECTED]
> > > Java Programming Specialist  www.landsend.com
> > > Lands' End, Inc.   (608) 935-4526
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> _
> Add photos to your messages with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-24 Thread Bueno Carlos M
I'm sure they were right on target -- remember the great laws of Brooks and
Lubarsky:

1. Thowing manpower at a late software project makes it later.
2. there's always one more bug.

And the hypothesis of equal time pressure:
Resources consumed will expand to the limits of resources available.


-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2003 5:52 PM
To: [EMAIL PROTECTED]
Subject: Re: [OT] Estimating a Struts-based project


But how close were your estimates?  You didn't say how far below the 
estimate you usually ended up.

David



>From: "Jeff Smith" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Subject: Re: [OT] Estimating a Struts-based project
>Date: Mon, 24 Mar 2003 15:47:27 -0700
>
>What? You don't increment the units as well?
>
>If I am looking for a safe estimate and a developer tells me 2 weeks, I
>automatically plan for 4 months. In all my years of experience I have NEVER
>gone over estimate with this method and I have been only been over by more
>than 20% 3 times in about 80 projects.
>
>Sad but true.
>
>Jefficus
>
>- Original Message -
>From: "Mark Galbreath" <[EMAIL PROTECTED]>
>To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
>Sent: Monday, March 24, 2003 10:31 AM
>Subject: RE: [OT] Estimating a Struts-based project
>
>
> > Okay, now double your estimate and you have a starting figure.
> >
> > -Original Message-
> > From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
> > Sent: Monday, March 24, 2003 12:21 PM
> > To: Struts Users Mailing List
> > Subject: RE: [OT] Estimating a Struts-based project
> >
> >
> >
> >
> > >-Original Message-
> > >From: James Mitchell [mailto:[EMAIL PROTECTED]
> > >Sent: Monday, March 24, 2003 11:18 AM
> > >To: Struts Users Mailing List
> > >Subject: Re: [OT] Estimating a Struts-based project
> >
> > 
> >
> > >Did you factor in the time for writing/maintaining tests?
> >
> > I'm hurt that you even felt you had to ask! ;-)
> >
> > Yes. As far as is possible, I have people write unit tests for code
>(before
> > if possible) and we are in the process of selecting further testing 
>tools
> > for good stuff like functional testing, load testing and performance
> > testing.
> >
> > Simon
> >
> > -
> > Simon P. Chappell [EMAIL PROTECTED]
> > Java Programming Specialist  www.landsend.com
> > Lands' End, Inc.   (608) 935-4526
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>


_
Add photos to your messages with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [OT] Estimating a Struts-based project

2003-03-24 Thread David Graham
But how close were your estimates?  You didn't say how far below the 
estimate you usually ended up.

David



From: "Jeff Smith" <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Subject: Re: [OT] Estimating a Struts-based project
Date: Mon, 24 Mar 2003 15:47:27 -0700
What? You don't increment the units as well?

If I am looking for a safe estimate and a developer tells me 2 weeks, I
automatically plan for 4 months. In all my years of experience I have NEVER
gone over estimate with this method and I have been only been over by more
than 20% 3 times in about 80 projects.
Sad but true.

Jefficus

- Original Message -
From: "Mark Galbreath" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Monday, March 24, 2003 10:31 AM
Subject: RE: [OT] Estimating a Struts-based project
> Okay, now double your estimate and you have a starting figure.
>
> -Original Message-
> From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 24, 2003 12:21 PM
> To: Struts Users Mailing List
> Subject: RE: [OT] Estimating a Struts-based project
>
>
>
>
> >-Original Message-----
> >From: James Mitchell [mailto:[EMAIL PROTECTED]
> >Sent: Monday, March 24, 2003 11:18 AM
> >To: Struts Users Mailing List
> >Subject: Re: [OT] Estimating a Struts-based project
>
> 
>
> >Did you factor in the time for writing/maintaining tests?
>
> I'm hurt that you even felt you had to ask! ;-)
>
> Yes. As far as is possible, I have people write unit tests for code
(before
> if possible) and we are in the process of selecting further testing 
tools
> for good stuff like functional testing, load testing and performance
> testing.
>
> Simon
>
> -
> Simon P. Chappell [EMAIL PROTECTED]
> Java Programming Specialist  www.landsend.com
> Lands' End, Inc.   (608) 935-4526
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


_
Add photos to your messages with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [OT] Estimating a Struts-based project

2003-03-24 Thread Jeff Smith
What? You don't increment the units as well?

If I am looking for a safe estimate and a developer tells me 2 weeks, I
automatically plan for 4 months. In all my years of experience I have NEVER
gone over estimate with this method and I have been only been over by more
than 20% 3 times in about 80 projects.

Sad but true.

Jefficus

- Original Message -
From: "Mark Galbreath" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Monday, March 24, 2003 10:31 AM
Subject: RE: [OT] Estimating a Struts-based project


> Okay, now double your estimate and you have a starting figure.
>
> -Original Message-
> From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 24, 2003 12:21 PM
> To: Struts Users Mailing List
> Subject: RE: [OT] Estimating a Struts-based project
>
>
>
>
> >-Original Message-
> >From: James Mitchell [mailto:[EMAIL PROTECTED]
> >Sent: Monday, March 24, 2003 11:18 AM
> >To: Struts Users Mailing List
> >Subject: Re: [OT] Estimating a Struts-based project
>
> 
>
> >Did you factor in the time for writing/maintaining tests?
>
> I'm hurt that you even felt you had to ask! ;-)
>
> Yes. As far as is possible, I have people write unit tests for code
(before
> if possible) and we are in the process of selecting further testing tools
> for good stuff like functional testing, load testing and performance
> testing.
>
> Simon
>
> -
> Simon P. Chappell [EMAIL PROTECTED]
> Java Programming Specialist  www.landsend.com
> Lands' End, Inc.   (608) 935-4526
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-24 Thread Sri Sankaran
W-H-A-A-T?  I can't hear you.  Can you speak up?!

-Original Message-
From: Chappell, Simon P [mailto:[EMAIL PROTECTED] 
Sent: Monday, March 24, 2003 12:39 PM
To: Struts Users Mailing List
Subject: RE: [OT] Estimating a Struts-based project


I usually triple them, but there's the damage to my hearing to take into account from 
listening to managers scream when they see my estimates.

>-Original Message-
>From: Mark Galbreath [mailto:[EMAIL PROTECTED]
>Sent: Monday, March 24, 2003 11:31 AM
>To: 'Struts Users Mailing List'
>Subject: RE: [OT] Estimating a Struts-based project
>
>
>Okay, now double your estimate and you have a starting figure.
>
>-Original Message-
>From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
>Sent: Monday, March 24, 2003 12:21 PM
>To: Struts Users Mailing List
>Subject: RE: [OT] Estimating a Struts-based project
>
>
>
>
>>-Original Message-
>>From: James Mitchell [mailto:[EMAIL PROTECTED]
>>Sent: Monday, March 24, 2003 11:18 AM
>>To: Struts Users Mailing List
>>Subject: Re: [OT] Estimating a Struts-based project
>
>
>
>>Did you factor in the time for writing/maintaining tests?
>
>I'm hurt that you even felt you had to ask! ;-)
>
>Yes. As far as is possible, I have people write unit tests for
>code (before
>if possible) and we are in the process of selecting further 
>testing tools
>for good stuff like functional testing, load testing and performance
>testing.
>
>Simon
>
>-
>Simon P. Chappell [EMAIL PROTECTED]
>Java Programming Specialist  www.landsend.com
>Lands' End, Inc.   (608) 935-4526
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-24 Thread Chappell, Simon P
I usually triple them, but there's the damage to my hearing to take into account from 
listening to managers scream when they see my estimates.

>-Original Message-
>From: Mark Galbreath [mailto:[EMAIL PROTECTED]
>Sent: Monday, March 24, 2003 11:31 AM
>To: 'Struts Users Mailing List'
>Subject: RE: [OT] Estimating a Struts-based project
>
>
>Okay, now double your estimate and you have a starting figure.
>
>-Original Message-
>From: Chappell, Simon P [mailto:[EMAIL PROTECTED] 
>Sent: Monday, March 24, 2003 12:21 PM
>To: Struts Users Mailing List
>Subject: RE: [OT] Estimating a Struts-based project
>
>
>
>
>>-Original Message-
>>From: James Mitchell [mailto:[EMAIL PROTECTED]
>>Sent: Monday, March 24, 2003 11:18 AM
>>To: Struts Users Mailing List
>>Subject: Re: [OT] Estimating a Struts-based project
>
>
>
>>Did you factor in the time for writing/maintaining tests?
>
>I'm hurt that you even felt you had to ask! ;-)
>
>Yes. As far as is possible, I have people write unit tests for 
>code (before
>if possible) and we are in the process of selecting further 
>testing tools
>for good stuff like functional testing, load testing and performance
>testing.
>
>Simon
>
>-
>Simon P. Chappell [EMAIL PROTECTED]
>Java Programming Specialist  www.landsend.com
>Lands' End, Inc.   (608) 935-4526
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-24 Thread Mark Galbreath
Okay, now double your estimate and you have a starting figure.

-Original Message-
From: Chappell, Simon P [mailto:[EMAIL PROTECTED] 
Sent: Monday, March 24, 2003 12:21 PM
To: Struts Users Mailing List
Subject: RE: [OT] Estimating a Struts-based project




>-Original Message-
>From: James Mitchell [mailto:[EMAIL PROTECTED]
>Sent: Monday, March 24, 2003 11:18 AM
>To: Struts Users Mailing List
>Subject: Re: [OT] Estimating a Struts-based project



>Did you factor in the time for writing/maintaining tests?

I'm hurt that you even felt you had to ask! ;-)

Yes. As far as is possible, I have people write unit tests for code (before
if possible) and we are in the process of selecting further testing tools
for good stuff like functional testing, load testing and performance
testing.

Simon

-
Simon P. Chappell [EMAIL PROTECTED]
Java Programming Specialist  www.landsend.com
Lands' End, Inc.   (608) 935-4526

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [OT] Estimating a Struts-based project

2003-03-24 Thread Chappell, Simon P


>-Original Message-
>From: James Mitchell [mailto:[EMAIL PROTECTED]
>Sent: Monday, March 24, 2003 11:18 AM
>To: Struts Users Mailing List
>Subject: Re: [OT] Estimating a Struts-based project



>Did you factor in the time for writing/maintaining tests?

I'm hurt that you even felt you had to ask! ;-)

Yes. As far as is possible, I have people write unit tests for code (before if 
possible) and we are in the process of selecting further testing tools for good stuff 
like functional testing, load testing and performance testing.

Simon

-
Simon P. Chappell [EMAIL PROTECTED]
Java Programming Specialist  www.landsend.com
Lands' End, Inc.   (608) 935-4526

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [OT] Estimating a Struts-based project

2003-03-24 Thread James Mitchell
On Mon, 2003-03-24 at 12:14, Chappell, Simon P wrote:
> I have just completed an initial estimate for a Struts-based web application. I am 
> curious as to what estimation methods folks out there use for their initial 
> estimates. The revised estimate will be delivered after more analysis is performed.
> 
> I am fed up with making wild guesses for initial estimates and wondered if there was 
> any way to take the small amount of information available up front (i.e. the number 
> of screens on the user's initial workflow requirements document) and extrapolate it 
> into an estimate. I understand that the margin of error is gonna be big and hairy on 
> this puppy, but it's an initial estimate created with a dearth of information, so 
> what do you expect? :-)
> 
> What I did was:
> 
> Take the estimated number of application screens: s=13
> Take the number of application user roles: r=3
> Figure which screens are used by which roles and total: sr=32
> Estimate the number of actions: a = sr * 2 = 64
> Application units of work: auow = a + sr = 96
> Total units of work (including admin screens): tuow = auow * 2 = 192
> Estimate an effort factor per unit: ef = 4hr
> Programmer work: pw = tuow * ef = 768hrs
> 
> Some assumptions included in these calculations include:
> 1. An average of two actions per screen role.
> 2. The administration facility of an application is about 50% of the work.
> 3. The effort factor is a figure arrived at from knowledge of the programmer being 
> tasked and the number of new technologies within the project.
> 
> Your thoughts please.

Did you factor in the time for writing/maintaining tests?

> 
> Simon
> 
> -
> Simon P. Chappell [EMAIL PROTECTED]
> Java Programming Specialist  www.landsend.com
> Lands' End, Inc.   (608) 935-4526
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
James Mitchell
Software Developer/Struts Evangelist
http://www.open-tools.org




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]