クラスA：
ソフトウェアのライフサイクルモデル：要件エンジニアリングソフトウェアの設計→→→ソフトウェア→ソフトウェアテストソフトウェアメンテナンスソフトウェア・デリバリー→
要求工学
：建築
ソリューション
主なタスク:(収集、分析、仕様、検証、管理）
要件開発
：需要が
取得
、需要
分析
、要件の
仕様
、要件の
検証
需要管理
方法：
構造化分析：DFD、ERD
オブジェクト指向分析法：ユースケース図、図概念的なクラス、行動モデル（シーケンス図、状態図）
ソフトウェア設計
：
どのように補完します
建築設計
：ハイレベル設計
構造化の方法：図の構造。
オブジェクト指向：図パッケージ図のメンバー、図デプロイ
主な製品：プロトタイプソフトウェアアーキテクチャ、ソフトウェアアーキテクチャ設計モデル、ソフトウェア・アーキテクチャ設計書（概要設計書）
詳細設計
構造化の方法：図の構造。
オブジェクト指向：図のパッケージ、クラス図、シーケンス図
主な製品：ソフトウェア詳細設計モデル、ソフトウェア詳細設計書
HCIデザイン
：デザインの相互作用メカニズム、使いやすさ
ソフトウェア構成
：ソフトウェアコンポーネント
プログラミング、統合、テスト、デバッグ
ソフトウェアテスト
：保証製品の品質
ユニットテスト
統合テスト
システムテスト
方法：ホワイトボックスとブラックボックス
ソフトウェア配信
：ユーザーの製品納入
インストールと展開、ユーザートレーニング、文書化、サポート
ソフトウェア保守
：
メンテナンス、適応メンテナンス、是正保守、予防保守を改善
リバースエンジニアリング、リエンジニアリング、レガシー資産処分
ビル - 修復モデル（ビルドフィックスモデル）：
短所：基本的なライフサイクルを考慮していません。需要の信憑性のない分析ありません。私たちは、ソフトウェアアーキテクチャの品質を考慮していません。彼は保守性を考慮していませんでした。
スコープ：あまり厳しいポストメンテナンスプログラムが使用できるため、ソフトウェアのサイズは、非常に小さく、あまり厳しい品質です。
ウォーターフォールモデル
（滝モデル）：
別の相変換配列に規則相によります
。これは、それぞれの活動を検証しなければならないことを要求しています。
可能な繰り返し
、各活動の成果がなければなりません
確認し
、「
ドキュメント・ドリブン
」
要件エンジニアリングソフトウェアの設計→→→ソフトウェア→ソフトウェア保守→ソフトウェアテストソフトウェアの配信は
（何度も繰り返すことができます）。
短所：
高い期待ドキュメント
開発活動上の
デフォルトの線形
、
クライアントユーザの参加が十分ではありません
、
マイルストーンの粒度が粗すぎます
。
スコープ：需要は非常に成熟し、安定した、信頼性の高い技術、プロジェクトの適度な複雑されます。
インクリメンタル反復モデル
：
編成開発活動
複数の反復、並列滝の開発活動
。「
需要主導型
」
目的：
反復、増分配信、並行開発
長所：
より良い適用性があり
、短く、製品開発時間を助けることができるソフトウェアの並行開発は、プログレッシブ配信は、ユーザーからのフィードバックは、開発リスクを軽減高めることができます。
短所：明確なプロジェクトの見通しを完了する必要があり、メンバーがすでに構築一部を破壊することはできません参加。
スコープ：比較的安定し、フィールドを成熟。
進化モデル：
複数の反復、並列滝の開発活動
。
利点：
反復型開発
並行開発
ユーザーからのフィードバックの提供を強化し、徐々に
短所：
プロジェクトの範囲を決定することはできません
、プロジェクト全体が十分に把握されていない、後続の反復を簡単にビルドフィックスモードに退化します。
スコープ：
より頻繁に変更
、
の不安定な領域
大規模システムの開発。
プロトタイプモデル
（試作）：の使用に焦点を当て
使い捨てのプロトタイプ
（不確かな部分）ではなく
、進化のプロトタイプ
（試作品は、製品の一部となります）。
反復要件現像部（使い捨てのプロトタイプ）：プロトタイププロトタイプの設計要件→→→メンバープロトタイプ試作評価。
利点：
強化され
たクライアントのユーザーが
交換する
新しいフィールドに。
短所：の危険性を避けるために時間をもたらす試作
新たなリスク
、
プロトタイプを放棄したくないし
。
スコープ：ソフトウェア開発において、より不確実性。
スパイラルモデル
（スパイラルモデル）：なるべく早くも比較的高いリスクを解決するために。
リスク主導
。
反復と滝の組み合わせで、使用し
たプロトタイプの
不確実性のニーズに対応するために
利点：
リスクを減らすことができます
起因するプロジェクトを提起したリスクに、損失を減少させます。
短所：
自分の風をもたらす
危険性を、モデルが複雑すぎます。
スコープ：
大規模な高リスク・ソフトウェア・システム開発
。
知識の⼯知識ドメインソフトウェアエンジニアリング体：（SWEBOK）
第二版：（10）
ソフトウェアの
ライフサイクルの
知識：（5）
ソフトウェアの
要件
ソフトウェア
デザイン
ソフトウェアの
設定
ソフトウェア
テスト
ソフトウェア・
メンテナンス
ソフトウェア工学、
エンジニアリングの
知識：（5）（ソフトウェア
エンジニアリングが
必要な
コンフィギュレーションツールを
生産制御するための
プロセス
とソフトウェアの
品質を
）
ソフトウェア・
エンジニアリング・マネジメント
ソフトウェア
構成管理
ソフトウェア
エンジニアリングプロセス
ソフトウェア・エンジニアリング・
ツールと方法
ソフトウェア
の品質
新5の:(第三版）（
プロの
ソフトウェアエンジニアが学ぶ必要が
確率論
、
線形代数
、
高度な数学
やソフトウェア
エンジニアリング
）
ソフトウェア工学
プロフェッショナル・プラクティス
エンジニアリング経済学の
基礎
計算
の基礎
数学的
基礎
エンジニアリング
基盤
クラスC：
ラショナル統一プロセス：
ソフトウェアのライフサイクル：
初期、精緻化、建設
および
配信
基本的な考え方：繰り返し、要件管理、コンポーネントベースのアーキテクチャ、ビジュアル・モデリング、検証品質、コントロールチェンジ
RUPの仕立て
特長：
伝統的なベストプラクティスに描画
広いため
ソフトウェア・ツールのセットをサポートしています
短所：
メンテナンスの問題を考慮することなく、ソフトウェアの配信後
作物や構成が簡単な作業ではありません
アジャイルプロセス：
アジャイルマニフェスト：
個人とその開発プロセスとツールの価値間の通信
ソフトウェアは、広範な文書よりも優れて実行することができます
契約交渉を超えるカスタマーコラボレーション
フォローするステップ計画バイステップよりも変化に良好な応答
アジャイルの原則：
顧客満足度を可能にするための貴重なソフトウェアの可能性、連続配信とすぐに（1）
（2）であっても、プロジェクトの後半に、また、変更の要求を歓迎
（3）作業ソフトウェアの定期配信
（4）事業者や開発者は、毎日一緒に働かなければなりません
（5）やる気個人の周りのプロジェクトをビルドします
（6）最も効率的な情報伝達及び効果は、顔に顔であります
ソフトウェアを実行することができます（7）は、進行の主要な尺度であります
（8）は、持続可能な開発スピードを促進します
卓越した技術と優れたデザインに（9）、一定の注意が俊敏性を向上します
（10）シンプル
（11）最高のアーキテクチャ、要件、およびデザインは、自己組織化チームから出てきます
(12)反省
