how to manage a project!

Hi, someone already knows I'm working on a little server to play audio
files.

The question is on how to manage the project...

My "project leader" has bought a lot of books about software
engineering... and he is studing a lot of them...
He said to me to begin writing a document on the server... he call the
document ICD... Are three weeks I'm writing this document... In the
document I have to describe the general behavior of the server, define
the messagges he handle, describe any possible interaction of any
single messagge, if the message have ack or not etc etc etc.
I finished to write the sixth release of the document. He has just
read the document and has said that is ok but on the next release we
have to add other things. This will take another week of work more
review...
He said that after the ICD we have to write the document about
specification and than the document on the procedure test...

We are not a big company with a lot of people working on the
project... we have just four programmers in a little company that have
to work on a very big project. I'm wondering if this is a good way to
solve our problem... I believe that any metodology is good in relation
with the context...

what do you think ?!

news75 wrote:
> Hi, someone already knows I'm working on a little server to play audio
> files.
>
> The question is on how to manage the project...
>
> My "project leader" has bought a lot of books about software
> engineering... and he is studing a lot of them...
> He said to me to begin writing a document on the server... he call the
> document ICD... Are three weeks I'm writing this document... In the
> document I have to describe the general behavior of the server, define
> the messagges he handle, describe any possible interaction of any
> single messagge, if the message have ack or not etc etc etc.
> I finished to write the sixth release of the document. He has just
> read the document and has said that is ok but on the next release we
> have to add other things. This will take another week of work more
> review...
> He said that after the ICD we have to write the document about
> specification and than the document on the procedure test...
>
> We are not a big company with a lot of people working on the
> project... we have just four programmers in a little company that have
> to work on a very big project. I'm wondering if this is a good way to
> solve our problem... I believe that any metodology is good in relation
> with the context...
>
> what do you think ?!

Those books are teaching your boss to fear code. The books say the longer you
avoid code, the better that evil code will be when you finally write it.

Google these topics, with quotes:

"Test Driven Development"
"Big Requirements Up Front"

--
Phlip

news75 a écrit :
> Hi, someone already knows I'm working on a little server to play audio
> files.
>
> The question is on how to manage the project...
>
> My "project leader" has bought a lot of books about software
> engineering... and he is studing a lot of them...
> He said to me to begin writing a document on the server... he call the
> document ICD... Are three weeks I'm writing this document... In the
> document I have to describe the general behavior of the server, define
> the messagges he handle, describe any possible interaction of any
> single messagge, if the message have ack or not etc etc etc.
> I finished to write the sixth release of the document. He has just
> read the document and has said that is ok but on the next release we
> have to add other things. This will take another week of work more
> review...
> He said that after the ICD we have to write the document about
> specification and than the document on the procedure test...

DEVs prefer coding over any other task, but a software process in real
companies implies 15-25% of analysis and 45-60% of tests within a
complete software process which means coding is less than 1/4 of the
total time devoted to the project. Your boss is acting as good as
expected, and the asked documents are mandatory for anything else bigger
than a "toy"/student work. Despite you prefer coding, you will pass many
more time to document and test the project.
Like your leader reading about engineering, you should read about unit
testing (http://en.wikipedia.org/wiki/Unit_testing) and eXtreme
Programming (http://www.extremeprogramming.org/index.html,
http://www.xprogramming.com/xpmag/whatisxp.htm).
>
> We are not a big company with a lot of people working on the
> project... we have just four programmers in a little company that have
> to work on a very big project. I'm wondering if this is a good way to
> solve our problem... I believe that any metodology is good in relation
> with the context...

Because the targeted application is a server, your team must freeze its
API before anything else, which include code writing. The "users" of the
server will write upon this API so it must be defined and stable (no
changes will be permitted once some application is plugged in it).
>
> what do you think ?!

Responding to News75...

> what do you think ?!

Documentation of various sorts is critical to large projects because of
the amount of communication required among the various stakeholders,
many of whom are not software developers. Much of the software
engineering literature is focused on milaero mega-projects with a cast
of thousands spread over several continents.

Small companies with small projects don't need a lot of documentation.
How much they need depends on what sorts of communication problems they
traditionally have had. So the general rule of thumb for how much
documentation a small shop needs is: whatever is necessary to eliminate
communication problems that have occurred in the past.

IOW, there should be a demonstrable need for the documentation _in the
product development environment in hand_. Corollary 1: once there is a
demonstrable need, do it. Corollary 2: after each project the team
should evaluate whether there were any communication problems and, if
so, look at process mechanisms (usually providing documentation) to
eliminate them in the future. (That review needs to include all the
stakeholders, not just the developers.)


--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

Vincent Mahe wrote:

> DEVs prefer coding over any other task, but a software process in real
> companies implies 15-25% of analysis and 45-60% of tests within a
> complete software process which means coding is less than 1/4 of the
> total time devoted to the project.

Right.

> Your boss is acting as good as
> expected,

Wrong. No activity should run for a long time in isolation from others. Most of
the books this boss reads don't recommend that, either.