Talk:Rapid application development

From Wikipedia, the free encyclopedia

 This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
??? This article has not yet received a rating on the quality scale.
??? This article has not yet received an rating on the importance scale.

Isn't there also an Interface Builder for Mac OS X?

Contents

[edit] Rapid application

== == == Advantages and disadvantages == == ==


jh

Rapid Application Development has two primary advantages: increased speed of development and increased quality. The speed increases are due to the use of CASE tools, the goal of which is to capture requirements and turn them into usable code as quickly as possible. Quality, as defined by RAD, is both the degree to which a delivered application meets the needs of users as well as the degree to which a delivered system has low maintenance costs. RAD increases quality {| class="wikitable"

|- through the involvement of the user in the analylsis and design stages |}.

RAD has two primary disadvantages: reduced Scalability, and reduced features. Reduced scalability occurs because a RAD developed application starts as a prototype and evolves into a finished application. Reduced features occur due to time boxing, where features are pushed to later versions in order to finish a release in a short amount of time.

Compared to what ? To the waterfall model ? Is there anything that woueld suggest the waterfall is any more scalable or results in programs that have more features ? Taw 21:09, 18 February 2006 (UTC)

Compared to the Waterfall model but more directly to traditional non-agile methodologies like SSADM (Structured Software Analysis and Design Model). As far as I understand, RAD (being a methodology) isn't really comparable to the Waterfall model (which is more of a software development life-cycle), the article should probably be changed to reflect this. Although I'm not totally sure so I'll leave the change for someone who has finished their Computer Science Degree :)
The waterfall model / SSADM is more scalable because 1) RAD isn't suited for very small projects, but mainly 2) It requires an unnecessary large amount of overhead for extremely large projects where the requirements are well defined with little ambiguity. RAD also can theoretically mean a product with less features 1) because the increase in managerial overhead may mean less time to spend implementing new features and 2) because features are more likely to be dropped from RAD due to it's emphasis on time boxing and avoiding project duration over-runs (so it's arguable the additional features would only be implemented in SSADM because the project is forced to run over-time to implement those features wheras in RAD, the customer would have the ability to drop the features to avoid the time over-run). Canderra 04:49, 8 May 2006 (UTC)

An what about "Pro: Decreased end-user functionality" ? I'd say that's a definate CON .. not a pro —Preceding unsigned comment added by 212.178.96.70 (talk) 06:11, 13 September 2007 (UTC)

I don't understand this Con. What data?

  1. The data needed should already exist —Preceding unsigned comment added by 131.128.81.206 (talk) 15:59, 16 January 2008 (UTC)

[edit] RAD is not scalable and reduced features...NOT TRUE ANYMORE!

Modern RAD tools now has the richest features and the most scalable.

RicoWiki 01:13, 26 June 2006 (UTC)

[edit] Stub status

I think this article isn't really a stub anymore?

Jaapvstr 10:11, 13 September 2006 (UTC)

I don't know, that's such a subjective thing... — Frecklefoot | Talk 15:23, 13 September 2006 (UTC)
Is subjective, but.... few would disagree that it is nolonger a stub now. Mathmo Talk 23:41, 8 May 2007 (UTC)

[edit] First language?

What was the first langauge to employ RAD techniques? Mathmo Talk 23:40, 8 May 2007 (UTC)

[edit] What the hell is it?

The more webpages I find talking about RAD, the more it sounds like a buzzword (just like Web 2.0). Here I see pros and cons, history, more on why it's useful... but not what it is. What, a programmer is supposed to buy a book to know "how to program using RAD"??

[edit] More Pro and Con commentary

On 5 February 2008 Gingerbits (talk) added this Pro:

End Users relate better to something tangible: as opposed to a written specification. Early visibility of even a mock up application can highlight differences between what End Users thought they wanted. or were going to get, and the reality being developed. Gingerbits (talk) 17:40, 5 February 2008 (UTC)

and these commentaries on the following Cons:

Reduced features occur due to time boxing when features are pushed to later versions in order to finish a release in a short amount of time
This is not always a Con (see 2. above). Time Boxing causes End Users to concentrate on what they need the most. Without this focus 'nice to have's' can creep into the solution and then are often never used. Gingerbits (talk) 17:40, 5 February 2008 (UTC)
The data needed should already exist.
This is not a prerequisite but does represent an issue. More problematic is complex data structures or high transaction volumes. In these both of these cases the database design needs to be fine tuned which means A. The prototype application has to be changed to work with the new schema and B. efficient database design takes time - negating some of the value of a RAD approach. Gingerbits (talk) 17:40, 5 February 2008 (UTC)

Seeing as he signed the edits I've assumed they're opinion (even though I agree with them) and undone the edits in the article. Mark Hurd (talk) 08:50, 7 February 2008 (UTC)