Re: Rapid Application Development
- From: "Phlip" <phlipcpp@xxxxxxxxx>
- Date: Sat, 15 Jul 2006 13:52:04 GMT
itsyash wrote:
I work in a BPO company where we have a small software team of 3-4
programmers. Because our core competency is BPO, our software team has
been functioning without any docuemnation till now. We are unable to
follow the regular SDLC documentation because we need to develop
applications very quickly based on the deadline from the Top
Management.
That is a perfect situation for development. Top Management knows which
features they want, short term, so you write those features, deliver, and
repeat.
Now, what do you think "the regular SDLC" is??
I heard about Rapid application development and wanted to know if there
is a way of structured documentation process for Rapid Application
Development. Our main need to document this is to ensure that the
requirement is correctly understood by us, to be able to transfer
system understanding to the new programmers quickly and maintain
quality. However, we are never going to be able to follow the detailed
documentation structure of flowcharting, algorithms, dfd's, SRS,
modular breakdown documents, testing reports etc.
RAD _was_ an initiative to rapidly develop applications by using tools -
debuggers, form painters, instant database kits - that offloaded much effort
from programming. When they are used as a one-shot for simple projects.
The ideal was that certain aspects of quality - up to and including bugs the
user won't notice - were acceptable so long as the software was low
availability, profitable to the user, and frequently released.
Is there a way to skip a few of these and still maintain quality
documentation to meet the above mentioned goals.
You have a myth that "proper documentation" will ensure high quality. It can
also reinforce low quality.
It would be great if someone can help me out of this.
Look up "Test Driven Development", and start writing unit tests for all your
features. Run all tests before committing your code to a repository.
Then look up "Refactoring". That means making small changes to the code,
passing the tests, and repeating until the design is better. Always refactor
to aggressively simplify, between adding test cases and features.
The tests will form a very useful kind of documentation, and the design
should be too simple to require elaborate maps to learn it.
--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
.
- References:
- Rapid Application Development
- From: itsyash
- Rapid Application Development
- Prev by Date: Rapid Application Development
- Next by Date: all in one keygens top 15
- Previous by thread: Rapid Application Development
- Next by thread: Re: Rapid Application Development
- Index(es):
Relevant Pages
|
