• Development Time Estimate (Access All Versions)

    Home » Forums » AskWoody support » Productivity software by function » MS Access and database help » Development Time Estimate (Access All Versions)

    • This topic has 5 replies, 6 voices, and was last updated 19 years ago.
    Author
    Topic
    #431907

    I’m curious about how others estimate the amount of development time required for a database.
    This time before I start developing my next database I’m going to make some forecasts and then see how reality matches up. This is because I’m apparently insanely optimistic about how fast I work…
    This is what I have so far:
    Everything depends on an estimate of the number of tables required by the db.
    So if my initial estimate is 10 tables:
    Tables:
    10 tables x 1.3(to catch the tables I didn’t include in the initial estimate) = 13 tables x .5 hr per table = 6.5 hours of table design and creation (gee that sounds like a lot)
    Reports:
    13 tables x 0.7(because there aren’t quite as many reports as tables) = 9 reports x 1.7 hrs per report = 15.3 hours of report design (well I know report tweaking is a big time sink for me)
    Forms:
    13 tables + (9/2) or 1/2 the number of reports rounded up = 18 forms x 1.7 hours per form = 30.6 hours of form design. (This should help account for time spent in coding)
    Queries: (obviously complex dbs will have a higher ratio of queries)
    9 reports + 18 forms = 27 queries x 1.5 (this is the factor used to account for db complexity) = 41 queries x 1 hour per query = 41 hours of query design (seems like way too much, but I know I’m too optimistic normally)
    Total 93.4 hours

    Additional Items to include in time estimate:
    Planning Meetings
    Documentation Creation
    Installation
    If anyone has any comments on this – I’d be interested to hear them.

    Cheers

    Viewing 4 reply threads
    Author
    Replies
    • #1012012

      An important factor is whether the data structure is standard/obvious, or new/complicated. If it is straightforward (either because it’s simple or because it’s something you’ve done before), the analysis and data design phases can be short, but otherwise, you shouldn’t underestimate the time needed to get a clear idea of the requirements and to translate it to a robust design. If you start creating tables etc. to soon, you might end up spending a lot more time because you have to modify the data structure halfway through.

      And don’t forget to include time for testing, and for modifications as a result of the testing. The times you mention are not unreasonable for the initial design, but additional tweaks can be time-consuming.

    • #1012013

      What about testing the system after it’s all put together? That should be a SIGNIFICANT chunk of time.

    • #1012019

      The time it takes to develop the objects you mentioned are directly related to the completeness, accuracy and customer signoff of :

      1. Defination of form, report and table layouts.
      2. Test data to verify the system.

      There are also three phases of an application:

      1. Rough draft – enough to confirm your approach and test the system
      2. Installation – good enough to get started
      3. Fine tuning

    • #1012030

      Like you I am always “insanely optimistic” about how much time is involved.

      So I would say : make your best estimate then double or triple it.

      There is another element that is not in your list that I find extremely time consuming – processes.

      e.g. an automated import, an automated mail merge, an automated emailing.
      These always involve creating a form where the user can specify what they want to do. The form itself usually takes hours because there will be numerous options to provide, then coding it all to happen takes even longer ( depending on how different it is to things you have done before).

      Yesterday I was working on a procedure for archiving data.
      Copy the back end file, then work through all the relevant tables in the correct order deleting data, according to the criteria specified on the form. It took most of the day, and I don’t think it is finished properly yet.

      Another thing to allow for is the unexpected. Something you think you have done 10 times before and is really straightforward, but this time it does not work. And you spend hours finding out what is wrong. The other day I was doing an import from Excel procedure, but I just kept getting an error message that gave me no clue as to the problem. Some time later I found that one of the column headings in Excel had a space before the first letter. Remove that and it all worked OK.

    • #1012064

      I would agree with John Hutchison – take your original estimate and double it. Testing & debugging may well take more time than the original design & development of the application. Joel Spolsky, author of “Joel on Software” and “User Interface Design for Programmers” (both recommended), maintains a web site on software development, Joel on Software. While not specifically related to Access programming, many of the articles should be of interest to anyone involved in the art, science (?), and business of software development, including Access developers. In reference to schedules and time estimates, see this article for some ideas:

      Painless Software Schedules

      HTH

    Viewing 4 reply threads
    Reply To: Development Time Estimate (Access All Versions)

    You can use BBCodes to format your content.
    Your account can't use all available BBCodes, they will be stripped before saving.

    Your information: