迅速なアプリケーション開発モデルを理解する

ラピッド アプリケーション開発 (RAD) は、ユーザーからのフィードバックを迅速に得るために、計画とプロトタイプの段階を重視するソフトウェア開発手法です。 予備設計とその後の実装を含む従来のソフトウェア開発方法と比較して、RAD は柔軟性を重視しています。 ユーザー入力の絶え間ないラウンドと急速な漸進的な改善により、1 日の終わりにより良い結果が得られます。

1990 年代、James Martin は、迅速なアプリケーション開発を従来のウォーターフォール手順に代わるものとして定義しました。 従来のウォーターフォール方式は、建設業界や、作業範囲の変更が珍しく費用がかかる多くの分野にとって優れたソリューションです。 橋の建設をすでに開始していた場合、橋の建設の途中でフェリーの建設に切り替えることはほとんどありません。

ソフトウェアの進歩により、高度な適応性が可能になります。 同じビジネス上の問題に取り組むために、より広い範囲のアプローチを使用することができ、変更はより低いコストで行うことができます。 その結果、企業は正確な設計と計画を犠牲にして、試行錯誤による反復プロセスを優先します。 さらに、消費者が改善を観察すると、建設的な批判をする可能性が高くなります。

迅速なアプリケーション開発は私のプロジェクトに適したアプローチですか?

前に説明したように、RAD は柔軟性のないコンテキストでは機能しません。 次の場合には適用されません。

• 財務上の制約とスケジュールの両方について事前に知っておく必要があります。
• ユーザーへの一貫したアクセス権がないか、プロジェクトに時間と労力を費やす意欲がありません。
• このプロジェクトは、その範囲の広さから、利害関係者として知られるかなりの数の人々の参加を必要とします。

これらの制限は、政府が運営する巨大な企業や組織に適用されることがよくあります。 一方、迅速なアプリケーション開発プロセスのいくつかの側面は、このような状況にも当てはまります。 たとえば、価格が設定されたプロジェクトでは、プロトタイプ段階と特定の数の改訂に資金を割り当てる場合があります。 適切なユーザーが参加している場合、プロトタイプの範囲を最も不明確な部分に制限できる場合があります。

一方、迅速なアプリケーション開発フレームワークは、小規模および中規模の組織や部門プロジェクトに非常に適しています。 これは、ビジネス ユーザーがお金を所有し、結果を達成するための意欲を持っている限りです。 これは、多くの基幹業務 (LOB) アプリの代表例です。 一般的な用語は、会社の特定の側面をより効果的に自動化および操作するソフトウェア プログラムを指します。

同様に、RAD は Web サイトを開発する際に効果的なアプローチです。 多くの場合、これらは限られた利害関係者のグループによるささやかなプロジェクトですが、デザインは非常に物議を醸すトピックであり、誰もがそれについて何か言いたいことがあるため、早い段階でそれらを含めることが不可欠です!

フェーズと方法論

時間のかかる計画段階は、迅速なアプリケーション開発アプローチの下で、より安価なプロトタイプ段階に置き換えられます。 具体的には、RAD モデルは、プロセスを次の 4 つの段階に分けることを提案しています。

所要量計画

ユーザーとプロジェクト チームは、このフェーズで協力して、将来のシステムの目標を決定します。 会社の成功が第一の関心事です。 基準はそれほど厳しくありません。 プロトタイプがまだ開発されている間に、それらを変更または適応させる能力が不可欠です。

ユーザーデザイン

高速アプリケーション開発手法は、ユーザー デザインをプロセスの基本コンポーネントとして強調することで、従来のウォーターフォール モデルとは異なります。 この段階で開発者が最初に行うことは、プロトタイプの作成です。 目的は、実演する必要があるものは何でも、顧客に迅速かつ手頃な価格で示すことです。 プロトタイプが一部の基準しか満たさない場合や、考えられる状況のサブセットしか処理できない場合は、取引を妨げるものではありません。 コーディングに関しては、近道をすることが許されています。

プロトタイプが完成したら、フィードバックのためにユーザーに見せます。 チームは可能な限り多くの情報を収集しますが、この段階では、必須の基準は避けられない変更の影響を受けやすくなっています。 書き留めたときに意味のあることは、実行に移すと別の外観になる可能性があります。 開発者はこの情報を得ると、プロトタイプ プロセスに戻り、消費者が最終結果に満足するまでそれを続けます。

工事

この時点で、満たさなければならない要件を十分に認識しています。 システムの開発とテストを完了して、本番環境で使用できるようにします。 もう近道はありません。 代わりに、品質、スケーラビリティ、保守性、およびその他の要素に重点が置かれます。 ただし、この遅い時点でも、消費者は新しい機能が導入されたときにコメントを提供することで対話を続けています. 迅速なアプリケーションを開発する反復プロセスのこの時点では、さらに微調整する余地がまだあります。

最終的に使用するツールや関連するその他の要因によっては、プロトタイプ作成プロセスのこの時点までに行った作業を使用することさえできません。

カットオーバー

これは、ユーザー トレーニング、受容性テスト、および新しいシステムの実装を含む最後のステップです。

迅速なアプリケーション開発対。 アジャイル

「RAD」という名前は、アジャイル開発方法論の 10 年前に造られたものであり、その反復的な方法論のために、RAD はアジャイルの「親」と呼ばれることがあります。 一方、これは状況ではありません。 アジャイルは、規範的な開発手法である RAD とは対照的に、単なるソフトウェア開発以上のものを包含する哲学的視点です。

ラピッド アプリケーション開発 (RAD) は、スクラム、かんばんなど、他のアジャイル ソフトウェア開発アプローチと同じファミリーのメンバーであると考えて間違いありません。

迅速なアプリケーション開発の利点と欠点

RAD により、焦点は予測可能性から離れて適応性に移ります。これには、良い意味と悪い意味の両方があります。

利点:

費用と危険の削減

ユーザーは、プロジェクトが配信された後にのみ、メソッドの結果を表示してコメントを提供できます。 この時点で行う必要がある避けられない調整には、時間と費用の両方がかかります。 迅速なアプリケーション開発プロセスを使用すると、実装後にソリューションの半分を書き直さなければならない可能性が大幅に減少します。

優れた品質

ユーザーがプロトタイピング プロセスに積極的に参加する場合、最終的なプログラムはおそらくユーザーのアクティビティにより適したものになるでしょう。 さらに、結果に関係なく、それは彼らの期待に応えます。

短所:

貧弱なデザイン

プロトタイプの段階で特定のビジネス ニーズを追求し、近道をすると、行き過ぎていることに気付くことがあります。 これにより、設計と全体的なソリューションが不十分になります。

効果的にスケールアップできない

RAD パラダイムは、チームとエンド ユーザーが非常に緊密に連携して協力することを前提としています。 チームが大きすぎるか、利害関係者の数が多すぎると、プロトタイプ プロセスは常に氷河期のペースで進みます。 さらに、プロジェクト範囲の頻繁な変更をすべての関係者に説明することは困難になります。 したがって、RAD は中規模または小規模のグループに最適に機能すると考えられています。

バックエンドでのお客様のこだわり

迅速なアプリケーション開発手法では、プロジェクトの存続期間中、かなりの量のユーザー入力が予想されます。 レポートによると、これは業界で最も有能な専門家に特に当てはまり、組織で最も忙しい個人でもあります.

コントロールできない

プロジェクトのプロトタイプ段階が完了する前に、プロジェクトのスコープ、予算、またはタイムラインを正確に予測することは、明らかな理由で実現不可能です。 ただし、要件計画プロセスの調査結果によっては、一般的な予測を確立することもできます。

迅速なアプリケーション開発 (RAD) のためのツール

RAD アプローチの適用は、主にラピッド プロトタイピングと緊密な協力に依存しています。 したがって、これらの取り組みを支援する適切なツールを選択することが最も重要です。 幸運なことに、選択できる膨大な選択肢があります。

設計と試作

Figma や InVision などの迅速なアプリケーション開発テクノロジにより、ビジュアル デザイナーと UX の専門家が共同で迅速に構築し、クリック可能なプロトタイプをエンド ユーザーと共有することが可能になります。 これらは完全な設計になっているため、開発者はユーザーの入力を収集できます。 プロトタイプの反復の 1 つにゴーサインが与えられるとすぐに、フロントエンド開発者が再利用できるようにプロジェクトをフォーマットにエクスポートできます。 したがって、建設段階への移行を示しています。 Web サイトの作成は、これらのツールの最も一般的な用途ですが、より複雑なエンドユーザー アプリまたはポータルのユーザー エクスペリエンスのプロトタイプを作成することも別の用途です。

ビジネス アナリストは、Balsamiq などの他のアプリケーションをはるかに頻繁に使用します。 彼らは、ワイヤーフレームを使用してユーザー エクスペリエンスのプロトタイプを作成することに集中しています。 その後、最終的な設計を後で実装します。 これらは、複雑なユーザー操作を含むより広範なシステムを予備的にモデル化するための優れたオプションです。

発達

アプリケーションを確立する開発フェーズは、多くの場合、最も時間がかかり、最もコストがかかり、最も重大な不確実性に満ちています。 したがって、迅速なアプリケーション開発のための現在のプラットフォームは、テスト済みのアーキテクチャを統合しています。 これらは、標準機能を実装する準備が整ったコンポーネントと、迅速な開発を容易にするツールです。 それらのすべてが、結果をより迅速に提供することを容易にします。 プロジェクトのプロトタイピング段階にいるか、建設段階にあるかに関係なく。

Gartner や Forrester などのコンサルティング会社は、これらの各プラットフォームを区別するために、常に新しい用語を開発しています。 多くの場合、ローコード/ノーコード アプリケーション プラットフォーム (LCAP)、サービスとしての高生産性アプリケーション プラットフォーム (HPAPaaS)、およびマルチ エクスペリエンス開発プラットフォームが含まれます。 これらはすべて、使用できるさまざまなタイプのアプリケーション プラットフォーム (MXDP) の例です。 ただし、最終的には、対象とする読者層に応じてそれぞれを分類できます。

ローコード/ノーコード プラットフォーム

これらのプラットフォームの背後にある基本的な概念は、コーディングの専門知識を持たないビジネス ユーザー (パワー ユーザーまたはシチズン デベロッパーとも呼ばれます) が機能するアプリケーションを迅速に提供できるようにすることです。 もちろん、この単純さには、柔軟性の欠如とさまざまな制限が伴います。 最近の記事では、これらの制限とその危険性について説明しています。 したがって、このようなプラットフォームのターゲット市場は、プロトタイプまたは基本的なソリューションのいずれかで構成されています。開発者向けプラットフォーム

これらのプラットフォームは、ソフトウェア開発の迅速さと興奮を利用しています。 主に、より高レベルの API の提供とコード生成を介して。 したがって、プログラマーは定型コードを繰り返し記述して標準機能を実装する必要がなくなります。

Embarcadero RAD Studio (以前は Borland Delphi) は、業界のパイオニアの 1 つです。 彼らは、視覚的なユーザー インターフェイスのデザインでよく知られています。 Borland Delphi はその姓でした。 これは Web が登場する前に存在し、デスクトップ コンピューターやモバイル デバイスのアプリに引き続き使用できます。

Web は、他の迅速なアプリケーション開発フレームワークの主要なターゲットです。 それは、現代の最終消費者とコミュニケーションをとるための最も一般的な方法だからです. たとえば、ここ Jmix では、ビジュアル データ モデルとインターフェイス デザインの使いやすさと迅速さを、今日のオープン ソース テクノロジの有効性と組み合わせる努力をしています。 この戦略により、プロトタイプを作成するペースが速くなります。 ただし、プロトタイプを開発して、安定したスケーラブルな構造を持つ完全な企業アプリケーションにすることもできます。

結論

アジャイルの考え方に従う開発アプローチの 1 つに、ラピッド アプリケーション開発 (RAD) があります。 エンド ユーザーの積極的な参加と、それらのユーザーからの入力を使用した迅速で反復的なプロトタイプの開発は、RAD 方法論の 2 つの中心的な原則です。 エンドユーザーの満足を確保した後、次は生産に適したソフトウェアの提供に注意を向けます。

適切なツールを選択することは、ラピッド プロトタイピングを確実にするために不可欠です。 その結果、特定のプロジェクト内で RAD 方法論が効果的に使用されます。 幸いなことに、使用するツールとプラットフォームにはさまざまな選択肢があります。 これらは、さまざまな種類のアプリケーション、プロジェクトのフェーズ、およびチームのスキル セットに対応します。

RAD は古いアイデアですが、現在はリバイバル中です。 これは、現在のデジタル トランスフォーメーションの傾向と、市場投入までの時間の短縮を目指す動きの直接的な結果です。 適切な種類のプロジェクトに適切な種類のチームで使用する場合、RAD アプローチはより少ないリスクとより短い時間でより多くの顧客満足度を達成する可能性があります。