[Linias]

Hi All,

New to the forum. :-)

So I was recently put in charge of our software design group. The problem that I have is that our software designers are really not designers. They are more like prototypers. We have a nice firm requirements team, and a development team. However what we have traditionally called "design" is really just Sr. Development.

So, I have been tasked to formalize the transition between Design and Development (what might be called a CDR). Now I have a lot of ideas about what this should include - does the design meet the requirements, is it "as simple as possible, but no simpler", is it portable, expandable, etc.

However, I am stuck in this whole loop of if what my guys are putting out are prototypes and not really design documents, then it's difficult (if not impossible) to answer some to most of these questions.

On the other hand if I make them all start documenting and not coding, I will have a mass exodus on my hands - not good. Nore are we about to hire twice as many so half can do design and have prototyping.

So... here is my real question(s)... Is it reasonable to jump from requirements to prototype and treat that as design, or do we really need design documents? to what level do we have to document before we can prototype? can I find a happy medium here where my guys will be happy and I don't need to repalce them all, but still satisfy our process of requireing a CDR? Any ides of how I can move toward a formal CDR without replacing the whole team which is not an option would be welcome.

Any and all opinions welcome!

Thanks!

[Martyn.Rae]

I really feel for your predicament. I too have been in a similar situation, but reversed. I had a 65 designers who could churn out hundreds and hundreds of pages of design document, but were absolutely not happy with producing code.

Your coders are producing prototypes to prove the requirements can be achieved, and this approach carries a great deal of merit.

Remember, the design document is only a means of ensuring that the requirements have been met before the expensive task of coding and testing begins. If your coders have been given requirements, then the prototypes they have produced can be viewed as proof that some if not most of the requirements have been met (assuming of course the prototypes work!).

The big problem for me would be when do you get them to stop prototyping and start coding the product? I would fear that the product will be a a series of spaghetti-like prototyped modules that will not perform very well in unison; will not provide a coherent product; will be unmaintainable, and neither expandable or extensible! Trust me, this will be the result if the stakeholders becomes impatient and wants to see results!!!

[Linias]

Thank you for the reply!

This still leaves me with the delimna of what do we put in the CDR, since our process requires that we undergo a design review before development...

[hookiethe1]

It seems like your team would do better with an agile development approach, it's all the rage at the moment, where you design and implement a little at a time in an iterative approach. That way your guys don't spend 6 months locked in a room writing requirements on a whiteboard, but they are still doing real design work with every iteration.
As you can see, there's a metric shitload of books on the subject:

http://www.amazon.co...ile+development