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!

  • 2
    This is non-responsive, so I'm not putting it in as an answer. But don't do it. Part of what your instructor wants is for you to organize your thinking and build your ability to plan and discuss a system you haven't yet written. Those are very good skills to have, and highly marketable once you're a few years into the programming business. Jan 16, 2012 at 14:08
  • Oh, okay. If I may ask, though, it does seem like some planning methods for getting requirements and conceptualising client-solutions involve prototyping a possible product --- is this a good way to help evolve or assist the planning and documentation stage? Or is that just an unreasonable desire?
    – blahman
    Jan 16, 2012 at 14:30
  • 2
    Sure, prototyping is valid. In fact, in a large company, you may find yourself building a prototype to justify capitalized R&D (it's an accounting thing, not a technical thing), even if you have no intention of using the prototype as the basis for the final system. In fact, the best prototypes are those that provide guidance and which are then discarded. If I had a nickel for every "productized" prototype that needed a total rewrite a couple of years later, I'd have a lot of nickels. Jan 16, 2012 at 19:28

1 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.

  • Thanks for your input! I've thought a little more about what you said and how I can apply it to my own projects. With a lot of our documentation, we're supposed to have a client to consult with, even though we have to submit by a deadline and make no meaningful modifications after that. Iterative development by client consultation is still possible, though? I mean, that's the point of developing in cycles, right?
    – blahman
    Jan 17, 2012 at 2:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.