![]() |
|
Keep It Simple, Stupid | |
PerlMonks |
large team v's small team developmentby g00n (Hermit) |
on May 13, 2003 at 01:22 UTC ( #257620=note: print w/replies, xml ) | Need Help?? |
Does any know of any good ... web-sites that define these documents A good site to see *real* as opposed to theoretical software engineering is www.joelonsoftware.com. There is enough good information for you to put aside the fact that Joel is an ex-microsofty ;) What are functional and technical design specifications? you can read more about specifications here (1. why, 2. what, 3. how, 4. tips) but this is where it gets a bit murky. Specifications mandated by traditional software engineering work well for large teams working on *certain types* of projects - (Joel was product manager for MS Excel embedded language specification - VBA) But these techniques are not as efficeint for small teams whose deliverables may not be shrink-wrapped. what about anti-specifications? Extreme programming on the other hand is a light weight development process that avoids some of the pitfalls of *documented specifications* especially where you are developing in small teams (1 >= member <= 30) where rapidly changing *business, technical and functional* requirements are the norm for a non shrink wrap market. So ask yourself what type of development will I be working with (large, small). What type of product will I be releasing (throw-away, internal, embedded, shrink wrapped?). Then check out the various different approaches to specification requirements in the links above.
In Section
Meditations
|
|