Rapid Application Development and Rapid Prototyping
Anonymous
Seeking input and experiences regarding implementing a rapid application development methodology and process. Have you done this? If so, can you share the methdodology or process you used?
Additionally, did rapid prototyping play into your methodology? Saving Changes...
I've used our "in house" rapid development method for the past 7 years implementing over 200 software dev projects.Is based on MSF methodology+remote software development process.Give me a buzz for more details: [email protected] Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
RAD is a given these days -- or at least should be. RAD takes requirements, design and construction phases and blends them into a series of iterative processes. In my experience the key to successful RAD are: 1 Creation of conceptual cross functional process maps that show the new application integrated into the workflow so users have a context to learn from 2 Development of “Functional” data models and dictionaries early on in the project (this becomes the foundation that the application will stand on) 3 Focus on developing the application as if it were going to be sold commercially. This means it must be completely parameter driven, design out need for IT intervention to keep it running, be professionally documented, etc. 4 Development of “look and feel” standards for user interfaces early on in the project. 5 Generation conceptual overviews (high level design) concepts that provide mind pictures for users to learn from. 6 Building prototypes that evolve into the actual application with frequent iterations with users (every 10 to 14 days works well) 7 Development of the application from high order tables towards transaction table so each new function can be tested as it evolves. I have used this approach for since the early 1980’s. While the tools have changed the process remains the same. The methodology used should support RAD at its roots. The risk in RAD is continuous scope creep and building applications that reflect personal preference and not enterprise requirements. The RAD team must understand the business and the work processes. The project goals must be clear and quantified. Good Luck.
2. building prototypes that evolve into the actual application with frequent itterations with users (every 10 to 14 days works well)
3. Creating conceptual process maps that show the new application integrated into the workflow so users have a context to learn from Saving Changes...
"Anyone can become angry - that is easy, but to be angry with the right person, to the right degree, at the right time, for the right purpose and in the right way - that is not easy."
