Developing Specs

[Daniel Pineault]

I can't find an old post I was looking for, so I have to re-ask a question
regarding developing a database.

How much time would you suggest be spent developing proper specification
prior to developing the database.

10% of the total project timeline
40%
....

Any online web resource that discuss this type of stuff (I can't seem to
find any)?

Thank you,

Daniel P

 

[microb0x]

I find it hard to even make that estimate. How can you know the % of
time you spent on writing specs in relation to the length of the
project, when you dont have all your specs yet? The very first step I
run though with the business users is a very detailed meeting(s) to go
over expectations and requirements. Only after all the specs have
been identified can you begin to draft a timeline of the project. So
in my opinion that requirements gathering phase is the most important
part of the project.

Thats just my 2 cents.

 

[Daniel Pineault]

I agree completly!

My issue is that I have a potential client who has come up with incomplete
(to say the least) specs and defined timeline without properly defining the
actual project reqs. Thus I'm trying to get authoritive documentation, web
resource, of some shape or form that would illustrate the importance of the
spec phase of a project and an idea of the amount of time one should spend
propery defining one's needs.

Thank you for your input!

Daniel P

 

[Larry Daugherty]

That's a very open question. It is just like asking "How many tables
should I use"? as though the number of tables had any meaning by
itself. The "Big Box" people, especially IBM, have studied the matter
while doing the best they could do in all respects. They found that
for any major release, by the time the specification was thoroughly
nailed down they had consumed 2/3 of all of the resources that would
be consumed by that release. That's right; 66 & 2/3 % of all
resources! And bear in mine that's for a project in which it was not
necessary to close the loop freeqeuently with the client,

My own experience includes some very reluctant client users and
managers who were serving as analysts who caused some projects to
really drag out. I've approached that 2/3 point several times.

The first real trick is to be clear on what you need for
specifications in order to get the job done. The core specifications
will have the same names across all projects but the amount of work
that goes into their creation and maintenance varies hugely. There is
no "one size fits all" .

My experience is that working with the client to develop the front end
documentation is the most important part of any project. When I get
the specifications nailed down, both the client and I sign them. That
becomes our "contract" and the measure of the project's completion.
That is the earliest point at which an accurate estimate for total
project cost can be made. Not a single piece of extra functionality
can be added to the project. New ideas will be addressed in a later
project or phasee.

There is a great book by Steve McConnell titled "Rapid Development".
Since Rapid Development was important to me, I bought it and read it.
It is filled with project development history and lore. Only when you
have read the entire book do you realize that he's never going to talk
about "Rapid". His unstated theme is that getting things right from
the outset is the only way to get to "Rapid".

My advice is to not worry overmuch about the percentage of
specification effort to total effort in a project. Like anything,
first get into the habit of doing things right. Then improve and
speed up the process. The quality and cost of the resulting
application are paramount measures.

HTH

 

[Pat Hartman]

Search for something on "the cost of change during the development life
cycle". Hopefully you'll find something that will tell you the approximate
cost of change at various stages. For example:
Definition Phase 1
Requirements Phase 3
Design Phase 5
Spec Phase 10
Coding Phase 20
Testing Phase 40
Implementation Phase 100

The result of analyzing a chart like this is a better understanding of the
cost of change. Something that would take an hour to change in the
definition phase could easily take 100 hours if it is not discovered until
you roll out the application. I would estimate that a minimum of 40% of the
overall project effort should be spent in the first four phases. When
developing with Access, we often skimp on these early phases because our
projects are frequently small in scope and the requirements are generally
understood. However, this is dangerous unless your user understands that in
a "program as you" go environment, there will be many back steps and
expensive schema changes even late into the lifecycle.

 

[Allen Browne]

Daniel, it depends what you do in writing the spec.

I would guess it 15% - 20% of the project for what I do. But that includes
developing the data structure too. I find until the structure is defined,
the spec is not tied down.

--
Allen Browne - Microsoft MVP. Perth, Western Australia

Reply to group, rather than allenbrowne at mvps dot org.

message
news:[email protected]...