迅速なアプリケーション開発

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

迅速なアプリケーション開発RAD )は、迅速なアプリケーション構築RAB )とも呼ばれ、適応型ソフトウェア開発アプローチの総称であり、 JamesMartinの迅速な開発方法の名前でもあります。一般に、ソフトウェア開発へのRADのアプローチは、計画を重視せず、適応プロセスを重視します。プロトタイプは、設計仕様に加えて、または設計仕様の代わりに使用されることがよくあります。

RADは、ユーザーインターフェイス要件によって駆動されるソフトウェアの開発に特に適しています(ただし、これに限定されません)グラフィカルユーザーインターフェイスビルダーは、多くの場合、迅速なアプリケーション開発ツールと呼ばれます。迅速な開発への他のアプローチには、アジャイルアジャイルスパイラル、および統合モデルが含まれます。

歴史

迅速なアプリケーション開発は構造化システム分析および設計手法(SSADM)などの1970年代および1980年代に開発された計画主導のウォーターフォールプロセスへの対応でしたこれらの方法の問題の1つは、橋や建物などの設計と構築に使用される従来のエンジニアリングモデルに基づいていることです。ソフトウェアは本質的に異なる種類のアーティファクトです。ソフトウェアは、問題を解決するために使用されるプロセス全体を根本的に変えることができます。その結果、開発プロセス自体から得られた知識は、ソリューションの要件と設計にフィードバックすることができます。[1]計画主導型のアプローチでは、要件、ソリューション、およびそれを実装するための計画を厳密に定義し、変更を阻止するプロセスを確立しようとします。一方、RADのアプローチは、ソフトウェア開発が知識集約型のプロセスであることを認識し、プロジェクト中に得られた知識を活用してソリューションを改善または適応させるのに役立つ柔軟なプロセスを提供します。

最初のそのようなRADの代替案は、Barry Boehmによって開発され、スパイラルモデルとして知られていましたベームと他のその後のRADアプローチは、厳密な設計仕様と同様に、またはその代わりに、プロトタイプの開発を強調しました。プロトタイプには、従来の仕様に比べていくつかの利点がありました。

  • リスク削減。プロトタイプは、ライフサイクルの早い段階でシステムの最も難しい潜在的な部分のいくつかをテストすることができます。これにより、設計の実現可能性に関する貴重な情報が提供され、チームが複雑すぎたり、実装に時間がかかることが判明したソリューションを追求することを防ぐことができます。問題を後からではなくライフサイクルの早い段階で発見するというこの利点は、RADアプローチの重要な利点でした。早期に問題を見つけることができれば、対処する方が安価です。
  • ユーザーは、仕様を作成するよりも、使用と反応に優れています。ウォーターフォールモデルでは、ユーザーが一連の要件を承認するのが一般的でしたが、実装されたシステムが提示されると、特定の設計にいくつかの重要な機能がないか、複雑すぎることに突然気づきました。一般に、ほとんどのユーザーは、実行中のシステムのプロトタイプを体験できるときに、そのシステムがどうあるべきかを抽象的に定義するのではなく、はるかに有用なフィードバックを提供します。
  • プロトタイプは使用可能であり、完成品に進化することができます。一部のRADメソッドで使用される1つのアプローチは、最小限の機能から中程度の有用性、そして最終的に完成したシステムに進化する一連のプロトタイプとしてシステムを構築することでした。上記の2つの利点に加えて、これの利点は、ユーザーがプロセスのかなり早い段階で有用なビジネス機能を取得できることでした。[2]

バリー・ベームのアイデアから始めて、ジェームズ・マーティンは1980年代にIBMで迅速なアプリケーション開発アプローチを開発し、1991年に「迅速なアプリケーション開発」という本を出版することで最終的にそれを形式化しました。これにより、ITプロフェッショナルの間でさえ、RADという用語について混乱が生じています。ウォーターフォールモデルの一般的な代替手段としてのRADと、Martinによって作成された特定の方法としてのRADを区別することが重要です。マーティンの方法は、知識集約型およびUI集約型のビジネスシステム向けに調整されました。

これらのアイデアは、ジェームズ・カーやリチャード・ハンターなどのRADの先駆者によってさらに発展し、改善されました。彼らは、RADのプロジェクトマネージャーがRADを運転して改良した後、このテーマに関する独創的な本[3]を共同で執筆しました。実際のRADプロジェクトのリアルタイムの方法論。これらの開業医、およびそれらのような開業医は、従来のシステムプロジェクトのライフサイクルアプローチの代替としてRADが人気を得るのを助けました。

RADアプローチは、ビジネスリエンジニアリングへの関心がピークに達した時期にも成熟しました。ビジネスプロセスリエンジニアリングのアイデアは、情報技術の新機能を念頭に置いて、販売や顧客サポートなどのコアビジネスプロセスを根本的に再考することでした。 RADは、多くの場合、大規模なビジネスリエンジニアリングプログラムの重要な部分でした。 RADのラピッドプロトタイピングアプローチは、テクノロジーがコアビジネスプロセスを根本的に再発明する革新的な方法について、ユーザーとアナリストが「箱から出して考える」のに役立つ重要なツールでした。[4] [5] [6]

ジェームズ・マーティンのRADに対する快適さの多くは、デュポンの情報エンジニアリング部門とそのリーダーであるスコットシュルツ、およびオーストラリアと香港で多くの成功したRADプロジェクトを開拓した特注のRAD開発会社を率いたジョンアンダーウッドとのそれぞれの関係に端を発しています。

ANZ銀行、レンドリース、BHP、コカコーラアマティル、アルカン、香港ジョッキークラブなどの成功したプロジェクト。

スコットシュルツとジェームズマーティンの両方がオーストラリアでジョンアンダーウッドと一緒に時間を過ごし、オーストラリアが重要なミッションクリティカルなRADプロジェクトの実施に不釣り合いに成功した理由の方法と詳細を理解することにつながった成功。

ジェームズマーティンRADメソッド

RADへのJamesMartinアプローチのフェーズ

RADへのJamesMartinのアプローチは、プロセスを4つの異なるフェーズに分割します。

  1. 要件計画フェーズシステム開発ライフサイクル(SDLC)のシステム計画フェーズとシステム分析フェーズの要素を組み合わせますユーザー、マネージャー、およびITスタッフは、ビジネスニーズ、プロジェクトスコープ、制約、およびシステム要件について話し合い、合意します。チームが重要な問題に同意し、続行するための管理権限を取得すると終了します。
  2. ユーザー設計フェーズ–このフェーズでは、ユーザーはシステムアナリストと対話し、すべてのシステムプロセス、入力、および出力を表すモデルとプロトタイプを開発します。 RADグループまたはサブグループは通常、共同アプリケーション設計(JAD)手法とCASEツールの組み合わせを使用して、ユーザーのニーズを実用的なモデルに変換します。ユーザーデザインは、ユーザーが自分のニーズを満たすシステムの動作モデルを理解し、変更し、最終的に承認できるようにする継続的なインタラクティブプロセスです。
  3. 構築フェーズ–SDLCと同様のプログラムおよびアプリケーション開発タスクに焦点を当てます。ただし、RADでは、ユーザーは引き続き参加し、実際の画面またはレポートが作成されるときに変更や改善を提案できます。そのタスクは、プログラミングとアプリケーション開発、コーディング、ユニット統合、およびシステムテストです。
  4. カットオーバーフェーズ–データ変換、テスト、新しいシステムへの切り替え、ユーザートレーニングなど、SDLC実装フェーズの最終タスクに似ています。従来の方法と比較して、プロセス全体が圧縮されています。その結果、新しいシステムが構築され、提供され、運用が開始されます。[7]

利点

現代の情報技術環境では、多くのシステムがある程度の迅速なアプリケーション開発[8]を使用して構築されています(必ずしもJames Martinのアプローチとは限りません)。マーティンの方法に加えて、アジャイル方法Rational UnifiedProcessがRAD開発によく使用されます。

RADの利点は次のとおりです。

  • より良い品質。ユーザーに進化するプロトタイプと対話させることにより、RADプロジェクトのビジネス機能は、ウォーターフォールモデルを介して達成されるものよりもはるかに高くなることがよくあります。ソフトウェアはより使いやすくなり、開発者が関心を持つ技術的な問題ではなく、エンドユーザーにとって重要なビジネス上の問題に集中できる可能性が高くなります。ただし、これには、セキュリティや移植性など、通常は非機能要件(AKA制約または品質属性)として知られている他のカテゴリは含まれません。
  • リスク管理。 RADに関する文献の多くは速度とユーザーの関与に焦点を当てていますが、正しく行われるRADの重要な機能はリスクの軽減です。ベームは当初、スパイラルモデルをリスクベースのアプローチとして特徴づけていたことを覚えておく価値があります。 RADアプローチは、主要なリスク要因に早期に焦点を合わせ、プロセスの初期段階で収集された経験的証拠に基づいてそれらに適応することができます。たとえば、システムの最も複雑な部分のいくつかのプロトタイピングの複雑さ。
  • より多くのプロジェクトが時間通りに予算内で完了しました。インクリメンタルユニットの開発に焦点を当てることにより、大規模なウォーターフォールプロジェクトを妨害する壊滅的な障害の可能性が減少します。ウォーターフォールモデルでは、システム全体の抜本的な再考を必要とする6か月以上の分析と開発の後に実現するのが一般的でした。RADを使用すると、この種の情報をプロセスの早い段階で発見して対処することができます。[2] [9]

短所

RADの不利な点は次のとおりです。

  • 新しいアプローチのリスク。ほとんどのITショップにとって、RADは新しいアプローチであり、経験豊富な専門家が作業方法を再考する必要がありました。人間は事実上常に変化を嫌い、新しいツールや方法で行われるプロジェクトは、チームが学ぶ必要があるという理由だけで、最初は失敗する可能性が高くなります。
  • 非機能要件の強調の欠如。これは、通常の操作ではエンドユーザーには見えないことがよくあります。
  • 不足しているリソースの時間が必要です。 RADへの事実上すべてのアプローチに共通していることの1つは、ユーザーと開発者の間のライフサイクル全体を通してはるかに多くの相互作用があるということです。ウォーターフォールモデルでは、ユーザーは要件を定義し、開発者がシステムを作成するときにほとんど離れます。 RADでは、ユーザーは最初からプロジェクト全体に関与します。これには、企業がアプリケーションドメインの専門家の時間を積極的に投資する必要があります。パラドックスは、専門家が優れているほど、ドメインに精通しているほど、実際にビジネスを運営する必要があり、上司に時間を費やすよう説得するのが難しい場合があるということです。そのようなコミットメントがなければ、RADプロジェクトは成功しません。
  • 制御が少ない。RADの利点の1つは、柔軟で適応性のあるプロセスを提供することです。理想は、問題と機会の両方に迅速に適応できることです。柔軟性と制御の間には避けられないトレードオフがあり、一方が多いほど他方が少なくなります。プロジェクト( ライフクリティカルなソフトウェアなど)の価値が敏捷性以上の制御を行う場合、RADは適切ではありません。
  • 貧弱なデザイン。場合によっては、プロトタイプに焦点を当てすぎると、開発者が個々のコンポーネントに小さな変更を加え、全体的な設計を改善する可能性のあるシステムアーキテクチャの問題を無視する、「ハックアンドテスト」方法論になります。これは、システムのユーザーインターフェイスに非常に重点を置いているMartinのような方法論にとって特に問題になる可能性があります。[10]
  • スケーラビリティの欠如。RADは通常、中小規模のプロジェクトチームに焦点を当てています。上で引用した他の問題(設計と制御が少ない)は、非常に大規模なシステムにRADアプローチを使用する場合に特別な課題を提示します。[11] [12] [13]

も参照してください

参考文献

  1. ^ ブルックス、フレッド(1986)。Kugler、HJ(ed。)特効薬の本質とソフトウェアエンジニアリングの事故はありません (PDF)情報処理'86。Elsevier Science Publishers BV(北ホランド)。ISBN 0-444-70077-32014年7月2日取得
  2. ^ a b ベーム、バリー(1988年5月)。「ソフトウェア開発のスパイラルモデル」(PDF)IEEEコンピュータ土井10.1109 /2.59S2CID 17818292018年3月29日にオリジナル(PDF)からアーカイブされまし2014年7月1日取得  
  3. ^ カー、ジェームズM。; ハンター、リチャード(1993)。RADの内部:90日以内に完全に機能するシステムを構築する方法。マグロウヒル。ISBN 0-07-034223-7 
  4. ^ Drucker、Peter(2009年11月3日)。ポスト資本主義社会ハーパーコリンズの電子書籍。ISBN 978-0887306204
  5. ^ マーティン、ジェームズ(1991)。迅速なアプリケーション開発マクミラン。ISBN 0-02-376775-8
  6. ^ https://www.technobuzz.tech/2020/10/android.html
  7. ^ マーティン、ジェームズ(1991)。迅速なアプリケーション開発マクミラン。PP。  81-90ISBN 0-02-376775-8
  8. ^ 「ADの崩壊:それを再び一緒に戻す」(PDF)gartner.com.br 取得した13年4月2010年
  9. ^ ベック、ケント(2000)。エクストリームプログラミングの説明アディソンウェスリー。頁 3-7ISBN 0201616416
  10. ^ ガーバー、オーロナ; Van Der Merwe、Alta; アルバーツ、ロネル(2007年11月16〜18日)。「迅速な開発方法論の実際的な意味」。コンピュータサイエンスおよび情報技術教育会議の議事録、CSITEd-2007コンピュータサイエンスとIT教育会議モーリシャス。pp。233–245。CiteSeerX10.1.1.100.645_ ISBN  978-99903-87-47-6
  11. ^ Andrew Begel、Nachiappan Nagappan(2007年9月)。「産業コンテキストにおけるアジャイルソフトウェア開発の使用法と認識:探索的研究」(PDF)経験的ソフトウェア工学と測定に関する最初の国際シンポジウム(ESEM 2007)pp。255–264。土井10.1109 /esem.2007.12ISBN  978-0-7695-2886-1S2CID  1941370
  12. ^ Maximilien、EM; ウィリアムズ、L。(2003)。「IBMでのテスト駆動開発の評価」。ソフトウェア工学に関する第25回国際会議、2003年。議事録pp。564–569。土井10.1109 /icse.2003.1201238ISBN 0-7695-1877-XS2CID16919353 _
  13. ^ スティーブンス、マット; ローゼンバーグ、ダグ(2003)。リファクタリングされたエクストリームプログラミング:XPに対するケース土井10.1007 / 978-1-4302-0810-5ISBN 978-1-59059-096-6S2CID29042153 _

さらに読む