1.ソフトウェア開発モデル
- コンセプト：
软件开发模型（ソフトウェア開発モデル）は、すべてのソフトウェア開発プロセス、アクティビティとタスクの構造的枠組みを指します。 作用：ソフトウェア開発モデルが明確に視覚的に全体のソフトウェア開発プロセスを表現することができ、明確にプロジェクト作業のためのソフトウェア基盤として、達成することが主な活動とタスクを定義します。異なるソフトウェアシステムでは、さまざまなプログラミング言語や仕事、異なる管理方法と手段の使用に関わるさまざまなスキル要員のさまざまな方法を使って、ならびに異なるソフトウェアツールと異なるソフトウェア工学の使用を可能にする、さまざまな開発手法を使用することができます環境。
1.1。修正を行います
多くの製品が開発の「学習改革を実行して、」モデルを使用しています。このモデルでは、仕様もどちらが設計され软件随着客户的需要一次又一次地不断被修改、ユーザーの満足度まで、。これはまだ、適切な小さなプログラムのために同様のワークショップを開発するための方法ですが、このアプローチは、任意のサイズの開発は、主に不十分である缺点ことを。
- 計画と設計面の欠如、悪い方へ悪いから一定の変更を伴うソフトウェアの構造、修正するために継続することは不可能で作ります
- リスクの大きなソフトウェア開発者に、セクタのニーズを無視
- テストや手続きの保守性を考慮し、何のドキュメントが存在しませんでした、ソフトウェアのメンテナンスが非常に困難です
1.2。ウォーターフォールモデル
ソフトウェアのライフサイクルのウォーターフォールモデルは、計画、要件分析、ソフトウェア設計、プログラミング、ソフトウェアのテストと操作と6つの基本活動の維持に分割され、上から下に彼らのために提供され、一定の秩序の相互の収束、水が落ちるように、徐々に落ちます。ソフトウェア開発のウォーターフォールモデルでは各项活动严格按照线性方式进行、活動上の現在アクティブな作業の結果を受け入れるために、必要なコンテンツの実装が完了します。作業現在アクティブの結果を需要进行验证次のアクティビティへの入力として、確認した場合、その結果、活性は、そうでなければ改変下で続けました。ウォーターフォールモデル强调文档的作用と尋ねます每个阶段都要仔细验证。しかし、このモデルの線形プロセスは太理想化、もはや現代のソフトウェア開発モデルに適していない、ほとんどの業界で放棄された、その主な欠点は、次のとおりです。
- 大幅に作業負荷を増大させる段階の間に文書の完全固定され、大量の様々な段階を分割
- 開発モデルは、このように発症の危険性を高め、結果だけを見るために、開発の全プロセスの最後まで線形、利用者であるので、
- 初期のミスは、開発テストフェーズの後半部分を見つけることができるまで、重大な結果を待たなければならないかもしれません
1.3。インクリメンタルモデル
また、進化のモデルとして知られています。インクリメンタルモデルでは、ソフトウェアは、設計、試験、および統合を実現するインクリメンタル部材の一連の通りであり、各部材は、増分モデル構成の相互作用によって形成されたコードフラグメントの種々のモジュールにより特定の機能を提供することです在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。製品は、1つのコンポーネントの開発者によって1が商品をお届けするために、いくつかのコンポーネントに分割され、そうすることの利点は、顧客が開発リスクを低減、ソフトウェア開発を見続けることができ、ソフトウェアの開発は、より良い変化に対応できるということです。しかし、インクリメンタルモデルは、次のを持っています缺陷：
- 各部材が徐々に構築部分に組み込まれているので、良好なシステム・ソフトウェア・アーキテクチャを有し、部材は、ソフトウェアを必要とするオープンアーキテクチャを含む、破壊するために添加されてはなりません
- 開発中は、需要の変化は避けられません。能力増分柔軟性のモデルにはウォーターフォールモデルとラピッドプロトタイピングモデルよりもはるかに優れたこれらの変化に適応するだけでなく、簡単に、モデルを変更することによって、学習に退化することができるようになるように、プロセス制御ソフトウェアの完全性の損失。
注意：
- インクリメンタルモデルを使用している場合
第一个增量往往是实现基本需求的核心产品。 - 評価を通じてユーザに配信コア製品後修飾およびコア製品の新機能の出版物を含む次の増分開発計画を、形成します。このプロセスは、最終的に完璧な製品まで各増分リリース後に繰り返されます
1.4。ラピッドプロトタイピングモデル
最初のステップは、ラピッドプロトタイピングモデルで建造一个快速原型，实现客户或未来的用户与系统的交互評価をプロトタイプに、ユーザーや顧客、さらにソフトウェアを開発するために洗練される必要があります。逐步调整原型使其满足客户的要求第2のステップは最初のステップに基づいて、顧客満足度のソフトウェア製品の開発であり、どのような顧客をしているKeyiqueding開発者の真のニーズ。明らかに、ラピッドプロトタイピング方法は、ウォーターフォールモデルの欠点を克服することができ减少由于软件需求不明确带来的开发风险、大きな効果があります。ラピッドプロトタイピングは关键在于尽可能快速地建造出软件原型、顧客の真のニーズと、プロトタイプの構築が破棄されます。重要なのはすぐにプロトタイプを構築する必要があるとしてそのため、プロトタイプシステムの内部構造は急速に顧客のニーズを反映させるために、プロトタイプを変更し、その後、ではありません。
1.5。スパイラルモデル
将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
- 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件
- 风险分析：分析评估所选方案，考虑如何识别和消除风险
- 实施工程：实施软件开发和验证
- 客户评估：评价开发工作，提出修正建议，制定下一步计划
螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制：
- 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发
- 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目
- 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险
一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。
1.6.喷泉模型
也称面向对象的生存期模型或OO模型，喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。
2.软件测试模型
软件测试和软件开发一样，都遵循软件工程原理，遵循管理学原理 。测试专家通过实践总结出了很多很好的测试模型。这些模型将测试活动进行了抽象，明确了测试与开发之间的关系，是测试管理的重要参考依据。
2.1.V模型
V模型目的是改进软件开发的效率和效果，是瀑布模型的变种：
- V模型明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系
- Vモデルは示しており、統合テストを実行するプログラムユニットは、ソフトウェアの設計要件を満たしているためにテストする必要があり、システムテストは、システムの機能を検出する必要があり、品質特性のパフォーマンス指標のシステム要件に達している。ソフトウェアは、ユーザーのニーズや契約を満たすかどうかを決定するためにテストの受け入れを達成します必要条件
局限：単に符号化後の試験段階として、テスト要件段階で入力されていません
2.2.Wモデル
Wモデル增加了软件各开发阶段中应同步进行的验证和确认活动。Wモデルを表す、2つのV字型のモデルで構成され、図明確な平行関係テストおよび開発に示す処理を。测试开发
- 特徴：オブジェクトが手続き、要件、設計、などの唯一のテストではありませんが、また、テストする必要があり、テストと開発が同時に行われます
- 長所：賛成
尽早地全面的发现问题。例えば、要件分析の完了後、テスト担当者は、問題をできるだけ早くどこにあるかを知るために、要件の検証と妥当性確認に関与すべきです。同時に、テストのための需要は、アイテムの難易度とテストリスクの後れを取らないためにも有益です、及早制定应对措施，显著减少总体测试时间，加快项目进度 - 制限事項：要件、設計、コーディングやその他の活動のシリアルとみなされ、テストおよび開発活動リニアコンテキストを維持するために、完全に仕事の次の段階の公式の開始前に、ステージ上で終えました。私たちは、アジャイル開発モデルをサポートすることはできません。現在の複雑で変化するソフトウェア開発のために、Wモデルとテスト管理は混乱を和らげるません直面しています
