Estimating time spent creating an MS Access application.

[qu1ncy]

Hello,

I've been asked to review the stucture of quite a few existing MS Access applications used throughout our corporation. The purpose is to estimate the number of hours it would take to recreate these apps. That number of hours will go to our internal audit people to place a value on these past projects.
The development time was not kept track of when these were being built years ago.

Has anyone done done this previously? I've developed quite number of MS Access apps in the past, but quite frankly, determining design, development, deployment (to production) times seems a lot subjective. Particularly with apps that one has not been involved with.

I would appreciate any suggestions you may have.
Thanks,
Q

 

[alvechurchdata]

I know I can design and build a system with a couple of tables and half a dozen forms in less than a day but also know it will have taken a couple of days discussion and thought to get the design together and it'll take me another few days to get a system that does exactly what the user wants (as opposed to what they asked for).

Very roughly I assume that each object in the database will take me a day's work. It's a crude estimate but it's quick and easy and it's the best I can come up with.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[qu1ncy]

Hi Geoff,

Thanks for your suggestion. Looking back at the development of apps I've had a hand in, your estimate for a small app will be a fair guideline to use for most MS Access apps, and as you mention, "quick & easy" which is a key consideration.

Appreciate your response.

Q

 

[alvechurchdata]

"quick & easy"

That was a typo. I meant "quick and dirty"<g>

Hope none of our clients are reading this.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[MichaelRed]

I would caution that the estimate may be reasonabvle for small apps. BUT my experience suggests that this doesn't hod true for larger ones. I would first be somewhat careful in 'defining' small apps. The size cited

" ... couple of tables and half a dozen forms ... "

seems to be a good starting point for that "Deffinition". As with most efforts in life, complexity grows with the "Size", but not at the nice linear rate, so the six object app noted to take a week week will probabably not scale to the 300 object app taking a year.

Another somewhat difficult portion is to scale an app (particularly a multiuser db) is the security. This deffinitly doesn't translate into the object per day.



MichaelRed

 

[psemianonymous]

Run. Just run.

While you're taking stock of the Access apps, find out what people are storing in Excel (and sometimes Outlook). If they're really out to find everything, this should scare them enough.

Seriously though: my recommendation would be to find out how many activities the database handles, or more specifically, what activities it handles. This way, you're partway to getting everything spec'ed, and you can apply estimates to all of this AFTER you have a complete list for one database.

I won't even dare try to guess how many (partial) hour(s) to estimate per activity, I won't even.

 

[qu1ncy]

Hello again,

Pseale's first suggestion is the one we'd like to adopt!
I thought I'd add these comments for all who have taken the time to respond.

I understand MichaelRed's perspective with the suggestion that as the size of a project increases, the linearity of "1 object equals 1 day" could lead to incorrect estimates. However, we're estimating in 'man/days' so I still think that a large project being undertaken by a single developer would not be far off the mark using this rough estimate.
Most large projects of that size (300 objects) would probably have a small team of people involved in it's creation which would cut down development time.

*Since posting this inquiry, I have since learnt that our internal audit folks are only data gathering for the consulting (accounting?) firm who will place the value on these applications. This consulting firm has a group of IT professionals who have recently offered the following guidelines for estimating:

Based on the figure that an average to a good developer can code 20 lines of code (LOC) per day. This estimate includes design/analysis/testing time frames.
(Oracle forms, reports, functions, packages, scripts, procedures) Classifications as simple, medium or a complex modules. A simple module is something that takes less than 3 days to complete and a medium module takes 3 to 5 days and a complex module takes more than 5 days to complete.
Translation: a module that has less than 60 (3*20) LOC is simple, a module that has between 60 (3*20) and 100 (5*20) LOC is medium and a module that has greater than 100 (5*20) LOC is complex.

Their estimation method indicated that this cannot be used for MS Access, Word, or Excel applications. Because MS Access Forms and Reports put a large chunk of code behind the GUI items automatically and it would invalidate the 20 LOC/Day formulas. We would have to use something like 500-600 LOC/Day.

I found this interesting and thought you might as well!

To summarize, my immediate team and I have been discussing this since Geoff Franklin's response and we all agree that his 'ballpark' estimate method is probably just as accurate as those of the consulting IT professionals.

Using Geoff's method would be less time consuming (and more efficient) of course, but would result in fewer billable hours... which I suspect would not sit well with the Partners in the consulting firm!
I guess efficiency doesn't always lead to retirement in the British Virgin Islands next door to one of the 'Partners'!

This post has turned out to be an interesting session. Hope my 'revelations' have been as interesting to you as yours has been useful to me and my colleagues.

Many thanks again,

Q

 

[RandyMyers]

One other concideration is that not all developers work at the same pace. I have seen people take a week to do something that anotehr might be able to do in a day. Some of us have become masters of copy, paste and modifying while others have not.

Also, one object / one day seems unrealistic. Some objects may take a few minutes, while an extremely involved form with lots of code on it could take conciderably longer.

Just some food for thought.