Hi, purplepit-ga:
I'm sorry I was unable to provide an excellent answer to your question
within the time frame you needed. If there's a looming deadline, it's
very helpful to us Google Answers Researchers to know about that at
the beginning.
In my experience the choice of development methodology is more closely
tied to these factors than to the "problem domain" per se:
- level of resources available (exp. of developers, mgrs.)
- architecture of proposed systems (familiar/novel, etc.)
- projected lifecycle of the software (inhouse, customized, shrink-wrap)
For example, an eXtreme Programming approach to developing software
requires two developers who sit side by side, switching off between
writing & compiling code and defining test cases. If the resources
are not there to support this approach, ie. if the developers are
individual telecommuters or have limited overlapping schedules in
cubicle-land, then this approach wouldn't work.
On the other hand a rigorous structured analysis approach requires a
commitment to capturing the systems requirements up front and
documenting any changes negotiated by the user/project management in a
form that is amenable to verfication against deliverables.
In my experience few development environments can support either of
these approaches. If you work for a company that is even willing to
seriously consider such issues, count yourself lucky!
A book I like to recommend before choosing a methodology is Peopleware
by DeMarco and Lister:
[Peopleware: Productive Projects and Teams (2nd ed.)]
http://www.dorsethouse.com/books/pw.html
You may already be familiar with it, and you might recommend it to your management.
regards, mathtalk-ga |