Is iterative documentation development possible, and does it deliver effective documentation?

Question

I have a project for university which I won't be starting immediately, but have been thinking about for a reasonably long amoung of time. I understand that University project development isn't like industry (I'm currently an intern myself) so the situation that I'll be pointing out at the moment will probably seem somewhat ridiculous to actual software developers. ^^'

The project itself requires that we document a lot of our work. So, besides delivering code, which counts toward some of the marks, we have to deliver documents including:

• A Requirements Analysis Document
• A Project Plan
• A planned list of Use Cases, Object and Dynamic Models and Acceptance Tests
• Documentation of the testing process and how successful the tests were
• Some other discussions and analyses of time usage, etc.

These deliverables are to be delivered in the following manner:

• RAD first
• Followed by Project Plan, Use Cases, Models and Tests (approximately 3 weeks later)
• Lastly, the documentation of the actual program, the testing process, etc. + the actual programming itself (approximately 5 weeks later)

So, from what I understand, this is really geared towards a Waterfall-style approach to the project. The only problem (in my opinion) is that this is a University project, and students already have enough pressure as it is with trying to develop projects at the end of semester during project week. I don't really want to be coding/developing/testing everything at the end of semester, when I'll be panicking with however many other assessments I have to deal with.

I'd like to at least try and do some sort of iterative development cycle that means we can start coding/prototyping early, have a continuous development cycle that isn't focused on doing everything at the last minute and not have so much pressure at the end of the semester to finish this project. And now comes my actual question(s):

• Can I somehow reconcile having to deliver all that documentation with a fast, iterative/prototyping development cycle?
• Are there strategies for generating documentation in an iterative manner?
• Am I being entirely unreasonable asking this and expecting it to be do-able in University?

Also, I understand that this question is extremely localised, so I'd like to ask the same questions that I asked above in terms of industry, and whether or not a lot of these kind of problems that agile processes face are different for each team or company.

Anyway, sorry about how long this is, and if you have finished reading all the way down, thank you! If you could take the time to answer, I'd be very grateful! Thank you!

Answer 1

The main concern (I have a similar problem with my job) is that if "The Process" demands that you deliver certain artifacts at certain times, and no one is allowed to challenge the almighty "The Process", then if you try, you will loose! It's not just a simple matter of it being a better way (Which iterative doc development is).

So what you need to do is work within the process, but find a way to work the way you want to as well. For instance, does your process allow document modification once submitted? If not, then no iterative develpment is possible. If so, then you need to think about the cost of delivery (In terms of your time, your credibilty etc), and manage that cost. If, for instance, its a file copy and nothing more, then go for it. If (like me) it's a peer review, revision release, impacts dozens of people and costs thousands of dollars, then think carefully and make sure the new document really adds value.

A common way to work is a bare essentials, minimum document that meets the needs of "The Process" at the start, followed later by a final "as built" update that not only reflects reality, but has the details where needed, and is brief where the code speaks for itself.