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

ソフトウェア開発モデルは、すべてのソフトウェア開発プロセス、アクティビティ、およびタスクの構造フレームワークを指します。一般的なソフトウェア開発モデルには、実行中変更モデル、ウォーターフォール モデル、ラピッド プロトタイピング モデル、インクリメンタル モデル、スパイラル モデル、エボリューション モデル、ファウンテン モデル、インテリジェント モデル、ハイブリッド モデル、および RAD モデルが含まれます。

ソフトウェア開発モデルとは、すべてのソフトウェア開発プロセス、アクティビティ、およびタスクの構造フレームワークを指します。

ソフトウェア開発には、要件、設計、コーディング、テストのフェーズが含まれ、場合によってはメンテナンスのフェーズも含まれます。ソフトウェア開発モデルは、ソフトウェア開発プロセス全体を明確かつ直観的に表現でき、完了すべき主なアクティビティとタスクを明確に規定し、ソフトウェア プロジェクト作業の基礎として使用されます。

異なるソフトウェア システムでは、異なる開発手法が採用され、異なるプログラミング言語が使用され、さまざまなスキルを持った人材が作業に参加し、異なる管理方法と手段が使用され、異なるソフトウェアが使用されます。ツールやさまざまなソフトウェア エンジニアリング環境。

典型的な開発モデル

1. 構築と修正のモデル

残念なことに、多くの製品は「変更に応じて変更」モデルを使用して開発されています。 。このモデルでは、仕様も設計も存在せず、ソフトウェアは顧客のニーズに応じて常に何度も修正されます。

このモデルでは、開発者はプロジェクトを取得し、要件に従ってすぐにそれを作成します。プログラムを作成すると、ソフトウェアの最初のバージョンが生成されます。ユーザーに提供された後、プログラムにエラーが発生したり、ユーザーから新たな要求があった場合には、開発者はユーザーが満足するまでコードを再修正します。

これはワークショップのような開発手法であり、数百行程度の小さなプログラムを書くのには悪くありませんが、どのような規模の開発にもこの手法は満足のいくものではありません。 ## (1) 計画と設計のリンクが欠如しており、継続的な変更によりソフトウェアの構造が悪化し、変更を継続できなくなる;

(2) 需要のリンクを無視し、ソフトウェア開発に大きな利益をもたらすリスク;

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

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

ウォーターフォール モデルでは、ソフトウェア開発のさまざまなアクティビティが厳密に線形的に実行され、現在のアクティビティは前のアクティビティの作業結果を受け入れて実装されます。必要な作業内容です。現在のアクティビティの作業結果を検証する必要があります。検証に合格した場合、その結果は次のアクティビティの入力として使用され、次のアクティビティが続行されます。そうでない場合は、変更のために返されます。

ウォーターフォール モデルでは文書化の役割が強調されており、各段階で慎重な検証が必要です。しかし、このモデルの線形プロセスは理想的すぎるため、現代のソフトウェア開発モデルには適さなくなり、業界からはほとんど放棄されています。その主な問題は次のとおりです。

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

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

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

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

ラピッド プロトタイピング モデルの最初のステップは、顧客または将来のユーザーとシステムの間の対話を実現するためのラピッド プロトタイプを構築することです。プロトタイプはさらに改良するために評価されます。開発するソフトウェアの要件。

顧客の要件を満たすようにプロトタイプを徐々に調整することで、開発者は顧客の本当のニーズが何かを判断できます。第 2 のステップは、最初のステップに基づいて、顧客を満足させるソフトウェア製品を開発します。

ラピッドプロトタイピング手法は、ウォーターフォールモデルの欠点を克服し、不明確なソフトウェア要件に起因する開発リスクを軽減できるため、大きな効果があることは明らかです。

ラピッド プロトタイピングの鍵は、ソフトウェア プロトタイプをできるだけ早く構築することです。顧客の真のニーズが決定されると、プロトタイプは破棄されます。したがって、プロトタイプ システムの内部構造は重要ではなく、プロトタイプを迅速に構築し、顧客のニーズを反映するために迅速に変更する必要があることが重要です。

4.増分モデル

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

# #5. スパイラル モデル

1988 年、バリー ベームは、ウォーターフォール モデルとラピッド プロトタイピング モデルを組み合わせたソフトウェア システム開発の「スパイラル モデル」を正式に発表し、他のモデルが無視したものを強調しました。大規模で複雑なシステム向け。

スパイラル モデルはスパイラルに沿って数回反復されます。図の 4 つの象限は次のアクティビティを表します:

(1) 計画の策定: ソフトウェアの目標を決定し、実装計画を選択し、Clear を開発します。プロジェクト開発の制約;

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

(3) 実装エンジニアリング: ソフトウェア開発を実装し、検証;

(4) 顧客評価: 開発作業を評価し、修正を提案し、次のステップを策定します。

スパイラル モデルはリスク主導型であり、ソフトウェアの再利用をサポートするための代替案と制約を強調し、特別な目標としてソフトウェアの品質を製品開発に統合するのに役立ちます。ただし、スパイラル モデルには次のような制限もあります。

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

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

(3) ソフトウェア開発者は、起こり得るリスクを探し、リスクを正確に分析することに優れている必要があります。そうしないと、より大きなリスクがもたらされます。

ステージの最初のステップは、ステージの目標を決定することです。これらの目標に向けたソリューションとその制約を選択し、リスクの観点からソリューションの開発戦略を分析し、場合によってはプロトタイプを構築することによって、さまざまな潜在的なリスクを排除しようとします。特定のリスクを排除できない場合、プログラムは直ちに終了され、そうでない場合は、次の開発ステップが開始されます。最後に、このフェーズの結果を評価し、次のフェーズを設計します。

6. 進化モデル

進化モデルは、グローバルなソフトウェア (または製品) ライフサイクル モデルです。反復型開発手法に属します。

モデルは次のように表現できます: 最初の反復 (要件 -> 設計 -> 実装 -> テスト -> 統合) -> フィードバック -> 2 番目の反復 (要件 -> ;設計- >実装->テスト->統合)->フィードバック->....

つまり、ユーザーの基本的なニーズに基づいて、ソフトウェアの初期実行可能バージョンが作成されます。迅速な分析を通じて構築され、この初期ソフトウェアは通常プロトタイプと呼ばれます。その後、プロトタイプの使用中にユーザーからの意見や提案に基づいてプロトタイプが改良され、新しいバージョンのプロトタイプが得られます。これを繰り返すことで、最終的にユーザーが満足するソフトウェア製品が完成します。進化モデルを使用した開発プロセスは、実際には、最初のプロトタイプから最終ソフトウェア製品まで徐々に進化するプロセスです。進化モデルは、ソフトウェア要件を正確に理解していない場合に特に役立ちます。

7. ファウンテン モデル

(オブジェクト指向ライフタイム モデル、OO モデルとも呼ばれます)

ファウンテン モデルと、より増分的かつ反復的な従来の構造化ライフタイムを比較します。性質上、ライフサイクル フェーズは重複して複数回繰り返すことができ、プロジェクトの存続期間全体にわたってサブライフサイクルを組み込むことができます。上に噴き上がった水がまた下に落ちるのと同じように、真ん中に落ちたり、下に落ちたりすることがあります。

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

インテリジェント モデルには、一連のツール (データ クエリ、レポート生成、データ処理、画面定義、コード生成、高レベルのグラフィックス関数やスプレッドシートなど)、各ツールを使用すると、開発者はソフトウェアの特定の機能を高レベルで定義でき、開発者が定義したこれらのソフトウェアのソース コードを自動的に生成します。

この方法では、第 4 世代言語 (4GL) のサポートが必要です。 4GL は第 3 世代の言語とは異なり、その主な特徴は、ユーザー インターフェイスが非常に使いやすく、訓練を受けていない非専門プログラマーでもプログラムを作成できることです。宣言型、対話型、非手続き型プログラミング言語です。 4GL は、効率的なプログラム コード、インテリジェントなデフォルト仮定、完全なデータベースおよびアプリケーション ジェネレーターも備えています。市場で人気のある 4GL (Foxpro など) はすべて、程度の差はあれ上記の特性を備えています。ただし、4GL は主に、トランザクション情報システムの中小規模のアプリケーションの開発に限定されています。

9.ハイブリッドモデル

プロセス開発モデルは、ハイブリッド モデルまたはメタモデルとも呼ばれます。複数の異なるモデルをハイブリッド モデルに組み合わせて、プロジェクトを最も効果的なパスに沿って開発できるようにします。これがプロセス開発モデル (またはハイブリッド モデル) ）。実際、一部のソフトウェア開発組織は、いくつかの異なる開発方法を使用して独自のハイブリッド モデルを形成しています。

10. RAD モデル

Rapid Application Development (RAD) モデルは、増分ソフトウェア開発プロセス モデルです。極めて短い開発サイクルを重視します。 RAD モデルはウォーターフォール モデルの「高速」バージョンで、再利用可能なコンポーネントを多数使用し、コンポーネントベースの構築手法を採用して迅速な開発を実現します。要件がよく理解され、プロジェクトの範囲が制限されている場合は、データ モデリング、プロセス モデリング、アプリケーションの生成、テスト、反復が行われます。 RAD モデルを使用したソフトウェア プロセスを右の図に示します。

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