一般的なソフトウェア開発モデルは何ですか?

一般的なソフトウェア開発モデルには次のものがあります: 1. 実行中変更モデル、2. ウォーターフォール モデル、3. ラピッド プロトタイピング モデル、4. インクリメンタル モデル、5. スパイラル モデル、6. ファウンテン モデル、7. インテリジェント モデル、6. モデル8. ハイブリッド モデル、9. RUP モデル、10. IPD モデル。

このチュートリアルの動作環境: Windows 10 システム、Dell G3 コンピューター。

一般的なソフトウェア開発モデルは次のとおりです:

1. 構築および修正モデル

申し訳ありませんが、多くの製品は「変更に応じて変更する」モデル。このモデルには仕様や設計はなく、顧客のニーズに応じてソフトウェアが何度も修正されます。このモデルでは、開発者はプロジェクトを取得し、要件に従ってすぐにプログラムを作成し、デバッグ後、ソフトウェアの最初のバージョンが生成されます。ユーザーに提供された後、プログラムにエラーが発生したり、ユーザーから新たな要求があった場合には、開発者はユーザーが満足するまでコードを再修正します。これはワークショップ形式の開発手法であり、数百行程度の小さなプログラムを書く場合には適していますが、どのような規模の開発においても不十分です。主な問題は次のとおりです。

(1) 計画の欠如およびデザインリンクは、修正を続けるとソフトウェアの構造が悪化し、修正を継続できなくなります;

(2) デマンドリンクの無視はソフトウェア開発に多大な影響をもたらします リスク;

(3) テストやプログラムの保守性が考慮されておらず、文書化されていないため、ソフトウェアの保守が非常に困難です。

2. ウォーターフォール モデル

1970 年にウィンストン ロイスが有名な「ウォーターフォール モデル」を提案しましたが、1980 年代初頭まではこれが唯一広く使用されていたモデルでした。ソフトウェア開発モデルを採用。ウォーターフォールモデルでは、図に示すように、ソフトウェアのライフサイクルを計画、需要分析、ソフトウェア設計、プログラム作成、ソフトウェアテスト、運用保守の6つの基本的な活動に分割し、それらがトップダウンで相互に関連した活動とします。滝のように、段階的に落ちる一定の順序。ウォーターフォールモデルでは、ソフトウェア開発のさまざまなアクティビティが厳密に線形的に実行され、現在のアクティビティは前のアクティビティの作業結果を受け入れて、必要な作業内容を実装します。現在のアクティビティの作業結果を検証する必要があります。検証に合格した場合、その結果は次のアクティビティの入力として使用され、次のアクティビティが続行されます。そうでない場合は、変更のために返されます。ウォーターフォール モデルでは文書化の役割が強調されており、各段階で慎重な検証が必要です。しかし、このモデルの線形プロセスは理想的すぎるため、現代のソフトウェア開発モデルには適さなくなり、業界からはほとんど放棄されています。その主な問題は次のとおりです。

#(2) 開発モデルがリニアであるため、開発結果は最後までしか確認できない

(3) 初期のエラーは、開発後期のテスト段階まで発見されない可能性があり、重大な結果を招く可能性があります。

「リニア」は、人々がそれを習得し、巧みに適用する最も簡単な方法であることを認識する必要があります。複雑な「非線形」問題に遭遇すると、人は常にそれを一連の単純な線形問題に分解または変換して、1 つずつ解決しようと最善を尽くします。ソフトウェア システムは全体として複雑かもしれませんが、単一のサブルーチンは常に単純で直線的に実装できます。そうしないと、作業が非常に疲れてしまいます。直線性は一種のシンプルさであり、シンプルさは美しさです。線形性の精神を理解すると、線形モデルの外観を厳密に適用するのではなく、それを利用する必要があります。たとえば、インクリメンタル モデルは本質的にセグメント化された線形モデルであり、スパイラル モデルは連続的な曲線の線形モデルですが、線形モデルの影は他のモデルにも見られます。

3. ラピッド プロトタイピング モデル

ラピッド プロトタイピング モデルの最初のステップは、顧客または将来のユーザーとシステムの間の対話を実現するためのラピッド プロトタイプを構築することです。ユーザーまたは顧客は対話的にプロトタイプを評価し、開発するソフトウェアの要件をさらに絞り込みます。顧客の要件を満たすようにプロトタイプを徐々に調整することで、開発者は顧客の本当のニーズが何であるかを判断できます。第 2 ステップは、最初のステップに基づいて、顧客を満足させるソフトウェア製品を開発します。明らかに、ラピッドプロトタイピング手法は、ウォーターフォールモデルの欠点を克服し、不明確なソフトウェア要件に起因する開発リスクを軽減でき、大きな効果をもたらします。ラピッド プロトタイピングの鍵は、ソフトウェア プロトタイプをできるだけ早く構築し、顧客の真のニーズが判明したらプロトタイプを破棄することです。したがって、プロトタイプ システムの内部構造は重要ではなく、プロトタイプを迅速に構築し、顧客のニーズを反映するために迅速に変更する必要があることが重要です。

4. 増分モデル

増分モデルは進化モデルとも呼ばれます。建物を建てるのと同じように、ソフトウェアも段階的に構築されます。インクリメンタル モデルでは、ソフトウェアは一連のインクリメンタル コンポーネントとして設計、実装、統合、テストされます。各コンポーネントは、複数の対話モジュールによって形成される特定の機能を提供するコード フラグメントで構成されます。インクリメンタル モデルは、各段階で完全な実行可能な製品を提供するのではなく、顧客のニーズを満たす実行可能な製品のサブセットを提供します。製品全体をいくつかのコンポーネントに分解し、開発者がコンポーネントごとに製品を提供することにより、ソフトウェア開発の変化への対応が容易になり、顧客は開発したソフトウェアを継続的に確認できるため、開発リスクが軽減されるという利点があります。ただし、インクリメンタル モデルには次の欠点もあります。

(1) 各コンポーネントは既存のソフトウェア アーキテクチャに徐々に統合されるため、コンポーネントの追加によって既に構築されたシステム部分が破壊されないようにする必要があります。建築。

(2) 開発プロセスでは、要件の変更は避けられません。インクリメンタル モデルの柔軟性により、そのような変更に適応する能力はウォーターフォール モデルやラピッド プロトタイピング モデルよりもはるかに優れていますが、同時に変更されるモデルに簡単に退化する可能性もあるため、ソフトウェア プロセスの制御が困難になります。誠実さを失います。インクリメンタル モデルを使用する場合、多くの場合、最初のインクリメントが基本的なニーズを満たすコア製品になります。コア製品がユーザーに提供された後、評価後に次の増分開発計画が作成されます。これには、コア製品の変更といくつかの新機能のリリースが含まれます。このプロセスは、段階的にリリースされるたびに、最終的な研磨された製品が製造されるまで繰り返されます。たとえば、増分モデルを使用してワードプロセッサ ソフトウェアを開発します。最初の増分は基本的なファイル管理、編集およびドキュメント生成機能をリリースし、2 番目の増分はより完全な編集およびドキュメント生成機能をリリースし、3 番目の増分はスペルと文法チェック機能を実装し、4 番目の増分はスペルと文法チェックを実装すると考えることができます。機能: 高度なページ レイアウト機能を段階的に完成させます。

5. スパイラル モデル

1988 年、バリー ベームは、ウォーターフォール モデルとラピッド プロトタイピングを組み合わせたソフトウェア システム開発の「スパイラル モデル」を正式に発表しました。を組み合わせて、他のモデルが無視するリスク分析を強調し、特に大規模で複雑なシステムに適しています。図に示すように、スパイラル モデルはスパイラルに沿って数回反復されます。図の 4 つの象限は次のアクティビティを表します:

(1) 計画を立てる: ソフトウェアの目標を決定し、実装計画を選択し、プロジェクト開発の制限を明確にし、

#(2) リスク分析: 選択したオプションを分析および評価し、リスクを特定して排除する方法を検討します。

##(3) 実装エンジニアリング: ソフトウェア開発の実装

##(4) 顧客評価: 開発作業を評価し、修正案を出し、次のステップを策定します。スパイラル モデルはリスク主導型であり、ソフトウェアの再利用をサポートするための代替案と制約を強調し、特別な目標としてソフトウェアの品質を製品開発に統合するのに役立ちます。ただし、スパイラル モデルには次のような制限もあります。

(1) スパイラル モデルはリスク分析を重視しますが、多くの顧客がこの分析を受け入れて信じ、適切な対応を行うことは容易ではありません。このモデルは多くの場合、社内の大規模ソフトウェア開発に適しています。

(2) リスク分析を行うことがプロジェクトの収益に大きく影響する場合、リスク分析を行う意味がないため、スパイラルモデルは大規模なソフトウェアプロジェクトにのみ適しています。

(3) ソフトウェア開発者は、起こり得るリスクを見つけ出し、リスクを正確に分析することに長けている必要があります。そうしないと、より大きなリスクがもたらされてしまいます。ステージでは、まずステージの目標、これらの目標を達成するためのオプションとその制約を決定し、次にリスクの観点からプログラムの開発戦略を分析し、場合によってはプロトタイプを構築することによって、さまざまな潜在的なリスクを排除しようとします。特定のリスクを排除できない場合、プログラムは直ちに終了され、そうでない場合は、次の開発ステップが開始されます。最後に、このフェーズの結果を評価し、次のフェーズを設計します。

6. ファウンテン モデル

ファウンテン モデル (オブジェクト指向ライフタイム モデル、OO モデルとも呼ばれます) ファウンテン モデルと従来の構造化ライフタイムと比較して、よりインクリメンタルなモデルです。ライフタイムの各フェーズは互いに重なり合って複数回繰り返すことができ、プロジェクトのライフタイム全体にサブライフタイムを組み込むこともできます。上に噴き上がった水がまた下に落ちるのと同じように、真ん中に落ちたり、下に落ちたりすることがあります。

7. インテリジェント モデル (第 4 世代テクノロジー (4GL))

インテリジェント モデルには一連のツール (データ クエリ、レポート生成、データ処理、画面定義、コード生成、高レベルのグラフィック関数やスプレッドシートなど) があり、開発者はそれぞれのツールを使用してソフトウェアを定義できます。特定の機能は、開発者によって定義されたこれらのソフトウェアのソース コードを自動的に生成します。このアプローチには、第 4 世代言語 (4GL) のサポートが必要です。 4GL は第 3 世代の言語とは異なり、その主な特徴は、ユーザー インターフェイスが非常に使いやすく、訓練を受けていない非専門プログラマーでもプログラムを作成できることです。宣言型、対話型、非手続き型プログラミング言語です。 4GL は、効率的なプログラム コード、インテリジェントなデフォルト仮定、完全なデータベースおよびアプリケーション ジェネレーターも備えています。現在市場に出ている人気の 4GL (Foxpro など) はすべて、程度の差はあれ上記の特性を備えています。ただし、4GL は現在、主に取引情報システムの中小規模のアプリケーションの開発に限定されています。

8. ハイブリッド モデル

ハイブリッド モデル (ハイブリッド モデル) プロセス開発モデルは、ハイブリッド モデル (ハイブリッド モデル)、またはメタ モデル (メタモデル) とも呼ばれます。モデル) は、いくつかの異なるモデルをハイブリッド モデルに結合し、最も効率的なパスに沿ってプロジェクトを開発できるようにします。これがプロセス開発モデル (またはハイブリッド モデル) です。実際、一部のソフトウェア開発組織は、いくつかの異なる開発方法を使用して独自のハイブリッド モデルを形成しています。さまざまなモデルの比較: 各ソフトウェア開発組織は、組織に適したソフトウェア開発モデルを選択し、現在開発中の特定の製品機能に合わせて変更して、選択したモデルの欠点を軽減し、その利点を最大限に活用する必要があります。表に、いくつかの一般的なモデルの長所と短所を示します。さまざまなモデルの長所と短所: モデルの長所 短所 ウォーターフォール モデル ドキュメント駆動システムは顧客のニーズを満たさない可能性がある ラピッド プロトタイピング モデル 顧客のニーズを満たすことに重点を置くと、システム設計が不十分になり、非効率になり、維持が困難になる可能性がある 増分モデル開発 早期のフィードバックはタイムリーであり、保守が容易 オープン アーキテクチャが必要ですが、設計が不十分で非効率である可能性があります。スパイラル モデルのリスク駆動型リスク アナリストは経験と十分なトレーニングが必要です。

9. RUP モデル (反復モデル)

RUP (Rational Unified Process) モデルは、Rational が提案する一連の開発プロセス モデルであり、オブジェクト指向ソフトウェア エンジニアリングの一般的なビジネス プロセスです。これは、同じ構造、つまり同じプロセス アーキテクチャを持つ、関連する一連のソフトウェア エンジニアリング プロセスについて説明します。 RUP は、エンドユーザーのニーズを満たす高品質のソフトウェアが予測可能なスケジュールと予算内で開発されることを保証することを目的として、開発組織内でタスクと責任を割り当てるための標準化された方法を提供します。 RUP には 2 つの軸があり、1 つは動的であるタイムラインです。もう 1 つの軸はワークフロー軸であり、静的です。タイムライン上では、RUP は初期段階、改良段階、構築段階、リリース段階の 4 つの段階に分かれています。反復の概念は各段階で使用されます。ワークフロー軸に関して、RUP は 6 つのコア ワークフローと 3 つのコア サポート ワークフローを設計しました。コア ワークフロー軸には、ビジネス モデリング ワークフロー、要件ワークフロー、分析および設計ワークフロー、実装ワークフロー、テスト ワークフロー、および公開ワークフローが含まれます。主要なサポート ワークフローには、環境ワークフロー、プロジェクト管理ワークフロー、構成および変更管理ワークフローが含まれます。 RUP は、最新のソフトウェア開発のベスト プラクティスをまとめ、さまざまなプロジェクトや組織のニーズに合わせた柔軟な形式を提供します。ビジネス モデルとして、非常に詳細なプロセス ガイダンスとテンプレートが用意されています。ただし、モデルが比較的複雑であるため、モデルを習得するには比較的多額のコストが必要になります。特に、プロジェクト マネージャーには比較的高い要件が課されます。これには次の特徴があります:

(1) 増分反復、各反復はウォーターフォール モデルに従い、初期段階でリスクを制御および解決します;

(2) モデルの複雑さによりプロジェクトが必要ですマネージャーは優れたマネジメント能力を持っています。

10. IPD モデル

IPD (Integrated Product Development) プロセスは、IBM が提案する一連の統合製品開発プロセスであり、複雑で大規模な開発に非常に適しています。開発プロジェクト、特にソフトウェアとハードウェアの組み合わせを含むプロジェクト。 IPDは製品全体の視点からスタートし、システムエンジニアリング、研究開発（ハードウェア、ソフトウェア、構造工業設計、試験、データ開発など）、製造、財務、マーケティング、調達、技術サポートなどこれはエンドツーエンドのプロセスです。 IPDプロセスは6つの段階（コンセプト段階、計画段階、開発段階、検証段階、リリース段階、ライフサイクル段階）と4つの意思決定レビューポイント（コンセプト段階の意思決定レビューポイント、計画段階の意思決定レビューポイント、可用性意思決定レビューポイント）に分かれています。ポイントとサポート終了決定レビュー ポイント)、および 6 つの技術レビュー ポイント。 IPD プロセスは、ウォーターフォール モデルの影を伴う段階的モデルです。このモデルは、大規模で複雑なシステムを分解し、包括的で複雑なプロセスを使用することでリスクを軽減します。このモデルは、ある程度、プロセスコストを使用して製品全体の品質を向上させ、市場シェアを獲得します。このプロセスはプロセスのロールバックのメカニズムを定義していないため、要件が頻繁に変更されるプロジェクトには適していません。また、一部の小規模プロジェクトでは、このプロセスはあまり適していません。

推奨学習:PHP 中国語 Web サイト

以上が一般的なソフトウェア開発モデルは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。