ソフトウェア エンジニアリング演習-part01-ソフトウェア エンジニアリングの概要とソフトウェア プロセス

コース紹介

「ソフトウェア工学」コースは、ソフトウェア工学専攻の中核となるコースであり、ソフトウェアの開発、保守、管理を工学的な手法で指導する総合的なコースであり、その内容はソフトウェアの解析、設計、実装、実装に関する理論と技術を含んでいます。メンテナンスとプロジェクト管理、メソッドと CASE ツール。

試験のシラバス

⚫ソフトウェア重点掌握工学基本概念および基本原理; ⚫ソフトウェア開発に対する中国のソフトウェア企業の現在のニーズに基づいて、ソフトウェア工学を習得し、実践的かつ基本的
にすることができます; ⚫ソフトウェア工学分野。运用基本原理软件开发技术管理技术
了解知识结构

⚫(1) ソフトウェア工学の概念とソフトウェア工学の基本要素
⚫(2) ソフトウェアプロセス
⚫(3) ソフトウェア要件とソフトウェア要件仕様
⚫(4) システム仕様とソフトウェア設計
⚫(5) ソフトウェアテスト
⚫(6) ソフトウェア工学管理⚫
(7) ソフトウェアの品質、品質特性およびソフトウェアの品質保証⚫
(8) コンピュータ支援ソフトウェアエンジニアリング CASE ツールおよび環境

ソフトウェア工学の概念とソフトウェア工学の基本要素

滝モデル

ソフトウェア製品モデル:

ソフトウェア プロセス モデル:

ソフトウェアプロセスモデルは、伝統的にソフトウェア開発モデルとも呼ばれ、ソフトウェア開発のプロセス、アクティビティ、およびタスク全体の構造的フレームワークです。典型的なソフトウェアプロセスには、ウォーターフォールモデル、インクリメンタルモデル、エボリューションモデル（プロトタイプモデル、スパイラルモデル）、ファウンテンモデル、コンポーネントベース開発モデル、フォーマルメソッドモデルなどがあります。

ソフトウェア プロジェクト モデル:
ソフトウェア テスト モデル:

Vモデル Wモデル Xモデル Hモデル アジャイルモデル

CMM サポート ソフトウェアの品質要素

CMM は、ソフトウェアの品質を支える要素には、プロセス、製品、および人員の 3 つの側面があると考えています。
製品、プロセス、および人
たとえば、
プロセスは開発者が確立されたプロセスに従ってソフトウェアを開発することを要求し、
製品は開発者が仕様を満たす製品を作成することを要求し、
人材は開発者が十分なスキルと経験を持っていることを要求します。
これらの要素が有機的に組み合わさることで、ソフトウェアの高品質が保証されます。

ソフトウェア エンジニアリングの品質は、主にソフトウェア エンジニアリングの 3 つの要素と呼ばれる方法、ツール、およびプロセスの 3 つの要因によって決まります。
メソッドは、ソフトウェア開発のさまざまなタスクを完了するための技術的な方法であり、ソフトウェア開発の「方法」技術を提供します。
ツールは、メソッドの適用のために提供される自動または半自動のソフトウェア エンジニアリング サポート環境です。
プロセスとは、高品質のソフトウェアを取得するために完了する必要がある一連のタスクのフレームワークであり、各タスクを完了するための作業手順、ソフトウェア エンジニアリング手法とソフトウェア ツールをどのように組み合わせてソフトウェアを合理的かつタイムリーに開発するかを指定します。 .

漸進的開発モデルに関する声明

ウォーターフォール モデルの基本コンポーネントとプロトタイプ実装の反復機能を統合することで、複数の利用可能なバージョンをリリースでき、多くの場合、コア機能が最初に完成します.これに基づいて、反復の各ラウンドで新しい増分リリースが行われます。コア機能を取得できます。十分にテスト済みです。増分ごとに運用成果物がリリースされることを強調します。
ウォーターフォール モデルの変形であるインクリメンタル モデルには、ウォーターフォール モデルのすべての利点があります。さらに、次の利点があります。

最初の成果物バージョンに必要なコストと時間が小さい 増分で表される小さなシステムを開発するためにとられるリスクが小さい 最初のバージョンが迅速にリリースされるため
、ユーザー要件の変更が少ない 量的投資、つまり、プロジェクトの開始時には、1 つまたは 2 つの増分にしか投資できません。

増分モデルには、次の欠点があります。

ユーザーの変更要件に対する計画がない場合、最初のインクリメントによって後続のインクリメントが不安定になる可能性があります。
要件が初期の思考ほど安定しておらず完全でない場合は、一部のインクリメントを再開発して再リリースする必要がある場合があります。
発生したコスト、スケジュール、および構成の複雑さを管理することは、組織の能力を超える可能性があります。

ソフトウェア プロセス モデルの誤った記述は、B のように感じます

ウォーターフォールモデルとファウンテンモデルの違い

ソフトウェア エンジニアリング活動:

ウォーターフォール モデル: さまざまなソフトウェア エンジニアリング活動と、その固定されたトップダウンおよび相互接続のシーケンスを規定します。まるで水の滝が段階的に落ちるようにです。実現可能性調査、要求分析、全体設計、詳細設計、コーディング、単体テストシステム、テスト受入、テスト運用と保守、

ファウンテンモデル：ファウンテンモデルは主にオブジェクト指向開発プロセスを説明するために使用され、「ファウンテン」という言葉はオブジェクト指向開発機能の反復的でシームレスなプロセスを反映しています。反復とは、モデルの開発作業を数回繰り返す必要がある場合が多いことを意味します。繰り返しのたびにターゲット システムのいくつかのプロパティが追加または明確化されますが、以前の作業の結果は実質的に変更されません。中断されない暗黙的とは、開発活動 (分析、設計、プログラミングなど) の間に明確な境界がないことを意味しますが、各開発活動は交差して反復的に進行することが許可されています。

ソフトウェア開発モデル:

まず、開発モデルにはいくつかの主な分類があります。プロトタイプ モデル、構造化モデル、オブジェクト指向モデル、Jackson モデルなどです。これらは明確な区分基準のない漠然とした分類概念です。
プロトタイプ モデルと構造化モデルを区別できることが重要です。この 2 つは補完的なものであり、他のモデルは特定の特性を把握するだけでよいため、ここでは詳しく説明しません。

参考:https://blog.csdn.net/Biu_Destiny/article/details/116893974

ライフサイクルの基本的なプロセスには、

ソフトウェア ライフ サイクル中に実行されるアクティビティは、次のように分類されます。

5 つの基本プロセス、
9 つのサポート プロセス
、7 つの組織プロセスが
あり、各ライフ サイクル プロセスはアクティビティのグループに分割され、各アクティビティはさらにタスクのグループに分割されます。

基本プロセス
生産に直接関係する活動
1. 調達プロセス：需要側、立ち上げ、入札、契約、供給者の監督、受け入れなどのために定義された活動 2. 供給プロセス：供給者のために定義された活動、立ち
上げ、準備 入札、契約調印、計画、実行、納品、完了
3. 開発プロセス: 開発者向けに定義された活動: 要件、設計、コーディング、テスト、インストール、受け入れ;
4. 運用プロセス: オペレーター向けに定義された 活動: テスト運用、システム運用、ユーザーサポート;
5. 保守プロセス: 保守担当者のために定義された活動: 問題および変更の分析、変更の実装、保守のレビュー/受け入れ、移行、ソフトウェア廃止サポート
プロセスの編成

プロセス

予算とスケジュールの作成は、CMMI のどのレベルに属しますか?

予算とスケジュールの編集は、CMMI 管理レベルの「プロジェクト計画」プロセス領域の専用プラクティスです√

CMM の 5 つのレベルの定義

1) 初期レベル (Initial): ソフトウェア開発プロセスに混乱が生じることがあり、厳密に定義された作業プロセスはごくわずかであり、開発の成功は特定の人の知恵と努力に依存することがよくあります。
2) 反復可能レベル (Repeatable): 基本的なプロジェクト管理プロセスが確立されている。機能を段階的に設計し、コストを追跡し、プロジェクト スケジュールに合わせて開発します。同様のプロジェクトでは、以前に開発に成功した部品を再利用できます。
3) 定義されたレベル (Defined): ソフトウェア開発のエンジニアリング活動と管理活動が文書化および標準化され、組織の標準開発プロセスに統合されます。すべてのプロジェクトの開発と保守は、この標準に基づいてカスタマイズされています。
4) 管理レベル (Managed): ソフトウェア開発プロセスと製品の品質テストの詳細が十分に要約されており、製品と開発プロセスの両方が定量的に分解および管理されています。
5) 最適化レベル (Optimizing): 開発プロセスに定量的なフィードバック機構を確立することで、常に新しいアイデアが生まれ、新しいテクノロジーを使用して開発プロセスが最適化されます。

この記事では以下を参照してください: 拡張 4.CMMI

RUP で使用されていないテクノロジ

参考：Unified Software Development Process (RUP)
RUP は、Rational Unified Process の統一された開発プロセスであり、使用されるテクノロジーは次のとおりです。

反復的かつ増分的なユースケース駆動型の
RUP は、ユースケース駆動型でアーキテクチャ中心の反復的かつ増分的なソフトウェア プロセス フレームワークであり、進化的な機能を提供します。

未使用のテクニックは次のとおりです。

テスト駆動開発
テスト駆動開発、英語の正式名称 テスト駆動開発は、TDD と呼ばれ、従来のソフトウェア開発プロセスとは異なる新しい開発方法です。ある関数のコードを書く前にテストコードを書き、テストをパスする関数コードだけを書き、テストを通して開発全体を進める必要があります。これにより、クリーンで使いやすく高品質なコードを記述し、開発プロセスをスピードアップできます。

ソフトウェアとは

ソフトウェアはソフトウェア工学の研究対象であり、ソフトウェア工学の製品形態であり客観的存在でもあります。
エンジニアリングは、実用的な問題を費用対効果の高い方法で解決することを目的として、理論と技術を実践に適用する科学です。

ソフトウェア＝プログラム＋データ＋ドキュメント

プログラム: 実行時に必要な機能とパフォーマンスを提供する一連の命令を受け入れるコンピュータ.
データ: プログラムが情報を適切に操作できるようにするデータ構造.
ドキュメンテーション: プログラムの開発プロセス、方法、および使用法を説明するグラフィカルな資料。

ソフトウェアには、複雑さ、一貫性、可変性、不可視性などがあります。

CMMIとは何ですか?CMMI連続表現では、能力レベルは何段階に分けられますか?

CMMI の正式名称は Capability Maturity Model Integration、つまり Capability Maturity Model Integration です。CMMI は、CMM モデルの最新バージョンです。
CMMI の正式名称は Capability Maturity Model Integration で、CMMI 認定には、
CMMI レベル 1 完了レベル、CMMI レベル 2 管理レベル、CMMI レベル 3 定義レベル、CMMI レベル 4 定量的管理レベル、CMMI レベルの 5 つのレベルがあります。 5、最適化レベル。

CMMI モデルでは、連続表現の使用をサポートするために、すべての CMMI モデルがその設計と内容に能力レベルを反映しています。CMMI の 4 つの能力レベルはレベル 0 からレベル 3 まで指定されており、各レベルは継続的なプロセス改善の基礎となるレベルです。

CMMI レベル 0.不完全なレベル
CMMI レベル 1.実行されたレベル
CMMI レベル 2.管理されたレベル
CMMI レベル 3.定義されたレベル
CMMI レベル 4.定量的管理レベル
CMMI レベル 5.最適化レベル

連続表現に基づくCMMIには、未完成レベル、実行レベル、管理レベル、定義レベル、定量管理レベル、最適化レベルに対応する合計6つの(0-5)能力レベルがあります。各能力レベルは、一般的な目標と、一連の一般的および具体的な実装手段に対応しています。能力レベル 0 は、プロセスが実行されないことを意味し、プロセス領域の 1 つまたは複数の特定の目的が満たされていないことを示します。能力レベル 1 は、特定の目的に焦点を当てて、識別可能なインプット作業成果物を変換することによって、プロセスが識別可能なアウトプット作業成果物を生成することを意味します。プロセス領域の目標. 目標の完了; 能力レベル 2 は、プロセスを管理されたプロセスとして制度化することを指し、単一のプロセスインスタンスの能力を対象とする. 能力レベル 3 は、プロセスを定義されたプロセスとして制度化することを指す.プロセスの組織レベルの標準化と展開について; 能力レベル 4 は、プロセスが定量的管理プロセスとして制度化されていることを指します; 能力レベル 5 は、プロセスが制度化された最適化されたプロセスとして言及されており、プロセスが適切に実行され、継続的に改善されていることを示します.

オープンソース ソフトウェアとは何か、例とともに

いわゆるオープン ソース、「ソース」はそのソース コードを指します。オープン ソースとは、ソフトウェアの作成者がソース コードをユーザーに無料で提供することを意味し、ユーザーは特定のオープン ソース仕様に従う必要があります。たとえば、Linux はオープン ソース ソフトウェアです。

RUP の各反復サイクルで 6 つのコア エンジニアリング ワークフローと 3 つのコア サポート ワークフローを設計し、6 つのコア ワークフローの名前と主な目標を説明する

参照:反復的な 2 次元開発モデルの 6 つのコア プロセス ワークフローと 3 つのコア サポート ワークフローの詳細な理解。

ビジネス モデリング ビジネス モデリング: ビジネス モデリングは、新しいターゲット組織のビジョンを開発する方法を記述し、このビジョンに基づいて、ビジネス ユース ケース モデルとビジネス オブジェクト モデルにおける組織のプロセスの役割と責任を定義します。要件分析要件: 要件ワークフローの目標です
。システムが何をすべきかの説明であり、開発者とユーザーはこの説明について合意に達していません。この目標を達成するために、要件の機能と制約が抽出され、整理され、文書化されます。最も重要なことは、システムによって解決される問題の定義と範囲が理解されることです。システム機能とユーザー インターフェイスを定義します。このワークフローの主な結果は、ソフトウェア要件仕様です。.
分析と設計 分析と設計: 分析と設計のワークフローは、要件を将来のシステムの設計に変換し、システムの堅牢な構造を開発し、設計を調整して、実装環境の残りの部分を互いに一致させ、そのパフォーマンスを最適化することです。解析設計結果は、設計モデルとオプションの解析モデルです。
実装: ワークフローを実装する目的は、コードの組織構造を階層サブシステムの形式で定義し、クラスとオブジェクトを実装し、開発されたコンポーネントで単体テストを実施し、単一の開発者のコ​​ンポーネントを統合して実行可能にすることです。システム。コードの組織構造を定義し、コード、単体テスト、およびシステム統合を実装します。
テスト テスト: 要件のキャプチャ、分析、設計、実装などの開発段階を完了し、ソース コードを取得したら、ソフトウェア製品のエラーや欠陥の可能性を探し始める必要があります。すべての要件が正しく実装されていることを確認し、すべてのエラーと欠陥がリリース前に発見されるようにします。
展開: 目的は、バージョンを生成し、ソフトウェアをエンド ユーザーに配布することです。展開ワークフローでは、ソフトウェアのパッケージ化、ソフトウェア自体以外の製品の作成、ソフトウェアのインストール、およびユーザーへの支援の提供について説明します。

構成および変更管理: 構成および変更管理のワークフローでは、複数メンバーのプロジェクトで多数の成果物を制御する方法について説明します。構成と変更のワークフローは、ソフトウェア プロセスの複数のリリースに続いて、進化するシステムで複数のトラバーサルを管理するためのガイドラインを提供します。ワークフローでは、並行して分散開発を行う方法と、プロジェクトを自動的に作成する方法について説明します。同時に、監査記録を維持するために、製品の変更の理由、時間、人員についても説明します。

プロジェクト管理: 目的には、プロジェクト管理のフレームワークと、計画、人員配置、および実行のガイドラインを提供することが含まれます。

環境: 環境ワークフローの目的は、プロセスやツールを含むソフトウェア開発環境をソフトウェア開発組織に提供することです。

ソフトウェア ライフ サイクルで実行される可能性のあるアクティビティは、5 つの基本プロセスに分けられます。5 つの基本プロセスとは何か、および各基本プロセスがソフトウェア プロジェクトのどの側に関連しているかです。

5 つの基本的なプロセス:

1. 調達プロセス: 需要側、立ち上げ、入札、契約、供給者の監督、受け入れなどのために定義された活動 2. 供給プロセス:
供給者のために定義された活動、立ち上げ、入札の準備、契約の署名、 3.開発
プロセス: 開発者向けに定義された活動: 要件、設計、コーディング、テスト、インストール、受け入れ
4. 運用プロセス: オペレーター向けに定義された活動: 実行中のテスト、システム操作、ユーザー サポート
5. 保守プロセス: 保守担当者向けに定義された活動: 問題および変更の分析、変更の実装、保守のレビュー/承認、移行、ソフトウェアの廃止

9 つのサポート プロセス:

1. 文書化プロセス
2. 構成管理プロセス
3. 品質保証プロセス
4. 検証プロセス: ソフトウェア製品が、以前の活動で課された要件と条件を満たしているかどうかを判断するプロセス。契約の検証、プロセスの検証、要件の検証、設計の検証、コーディングの検証、統合の検証、ドキュメントの
検証 このプロセスには、次のタスクが含まれます。

1. テスト結果の分析のために、選択したテスト要件、テスト ケース、およびテスト仕様を準備します
。 2. これらのテスト要件、テスト ケース、およびテスト仕様が、特定の使用目的の特定の要件を反映していることを確認します。
3. テストには、強度、境界、および例外が含まれます。入力テスト

6. 共同レビュー プロセス: プロジェクトの活動のステータスと成果物の評価、プロジェクト マネジメント レビュー、テクニカル レビュー
7. レビュー プロセス: 必要に応じて、要件、計画、および契約への準拠を決定する
8. 問題解決プロセス
9. ユーザビリティ プロセス

7 組織プロセス

1. 管理プロセス：プロジェクト管理を含むライフサイクルプロセスにおける管理のために定義された基本的な活動
2. インフラプロセス：ライフサイクルプロセスの基盤を確立するために定義された基本的な活動
3. 改善プロセス
4. 人的資源プロセス
5. 資産管理プロセス
6 . 再利用プログラム管理プロセス: 組織の再利用プログラム ディレクター、開始、ドメイン評価、再利用評価、計画、実行と管理、レビューと評価のために定義された活動 7. ドメイン エンジニアリング プロセス: ドメイン エンジニアの活動とタスク、ドメイン分析、ドメイン
設計、資産のプロビジョニング、資産のメンテナンス

拡大

1. ソフトウェア プロセス、ソフトウェア ライフ サイクル、およびソフトウェア プロセス モデル (ソフトウェア ライフ サイクル モデル) の概念上の違いを簡単に説明してください。

ソフトウェア プロセス:ソフトウェア ライフ サイクルの一連の関連プロセスに関与する活動です。プロセスは活動の集合であり、活動はタスクの集合であり、タスクは入力を出力に変換する操作です。
ソフトウェアのライフ サイクル:ソフトウェアの誕生から消滅までのプロセス。それは、実現可能性分析、プロジェクト計画、需要分析、ソフトウェア設計、コーディングとテスト、運用と保守の段階を含む、定義、開発、運用の 3 つのサイクルに分けることができます。
ソフトウェア プロセス モデル:ソフトウェア プロセスの抽象的な表現であり、特定の観点からプロセスを表現し、一般に直感的なグラフィックを使用してソフトウェア開発の複雑なプロセスを表現します。ソフトウェアプロセスモデルは、主にソフトウェアの種類や規模などのさまざまな要因、特にソフトウェアの開発方法や開発環境に応じて確立されます。

違い:
ソフトウェア ライフ サイクルはプロセスであり、本体はソフトウェアである;
ソフトウェア プロセスは、ソフトウェアの誕生からのプロセスおよびそのライフ サイクルであり、このプロセスに含まれる一連の活動である; ソフトウェア プロセス モデルは
、一連のアクティビティ (ソフトウェア プロセスの抽象表現)。

2. ソフトウェア プロセスはソフトウェア開発プロセスですか? なぜ？

いいえ。ソフトウェア開発プロセスはソフトウェアプロセスの一段階に過ぎず、ソフトウェア開発業務を請け負う主体によって、基本プロセス、支援プロセス、組織プロセスの3つに分類され、基本プロセスは取得プロセスに分けられる、供給プロセス、およびプロセス内のさまざまな主題に応じた供給プロセスプロセス、開発プロセス、運用プロセス、保守プロセス、したがって、ソフトウェア開発プロセスはソフトウェア開発プロセスの一部にすぎません。

3. ソフトウェア テスト モデル

参照: https://blog.csdn.net/WeirdoGiraffe/article/details/124883325
開発モデルと同様に、ソフトウェア テストは異なるものを採用できます。テスト モデルはテスト活動を実装して、ソフトウェア テスト活動の配置をガイドします。
業界で一般的なモデル:

1.Vモデル
2.Wモデル（ダブルVモデル）
3.Xモデル
4.Hモデル
5.アジャイルモデル

V型

V モデルは、すべてのソフトウェア テスト モデルの中で最もよく知られているモデルです。図に示すように、ウォーターフォール R&D モデルから進化したテスト モデルです。

V モデルのプロセスは、上から下、左から右へ
① テスト エンジニアは、R&D 担当者のプログラミング プロセス中に、生成されたコード関数の単体テストを実行します
② 単体テストに合格した後、統合テストを実行します
③ システム テストと受け入れを実行します統合テストに合格した後 test

V モデルの欠点:

プロジェクトの初期の欠陥は後で発見される

W型

WモデルはVモデルをベースに進化したもので、一般的にダブルVモデルと呼ばれています。V モデルでは、R&D 活動が完了せず、アウトプットがない場合、テスト エンジニアはテスト作業を実行できず、相対的に言えば、テスト活動は大幅に遅れています。Vモデルの欠点を解決するために、Wモデルは並行テスト活動と研究開発活動の概念を提唱し、生産プロセスの進化中に検証と確認活動を増やします。

Wモデルはユーザー要求から始まり、R&Dチームはユーザー要求に応じて要求分析、概略設計、詳細設計、コーディング開発などを行い、テストチームは受入テスト、システムテスト、統合テスト、単体テスト設計をベースに実施します。ユーザーの要件について。テスト作業は研究開発活動から分離されており、並行作業が可能です。テスト活動は、研究開発の結果が出力された後だけでなく、研究開発プロセス全体に伴います。
W モデルは、テスト活動が研究開発活動によって作成されたソフトウェア ソース コードを含むだけでなく、要求文書、一般的な設計文書、詳細設計文書、コードなどのさまざまな文書を考慮することを強調しています。
W モデルでは、ユーザー要件の段階からテスト活動を行う必要があるため、問題の早期発見につながります.モデルの実装プロセスでは、検証と検証の活動が常に行われます.

X モデル

X モデルの背景は V モデルにも関連していますが、V モデルの欠点は、テスト活動が研究開発活動に遅れをとっており、テスト活動をできるだけ早く実行できないことです。X モデルは、W モデルと同様に、もともと V モデルの欠点を解決するために提案されました。
X モデルの基本的なアイデアは Marick によって提案され、Robin F.Goldsmith によって改良されました。X モデルを図に示します。

X モデルの左側は、個々のプログラム断片 n に対する独立したコーディングとテスト活動を示しており、これを基本プロセスとして、継続的な反復を行い、最終的に統合活動を通じて実行可能プログラムになり、これらの実行可能プログラムをテストします。統合テストに合格した完成品は、パッケージ化してシステム テスト リンクに送信するか、ユーザーに直接送信できます。複数の平行な曲線は、さまざまな部分で変更が発生する可能性があることを示しています。
X モデルは、探索的テストの概念を提示します。探索的テストは、従来のテスト方法とは異なり、事前にテスト計画や設計を作成する必要はありません.経験豊富なテストエンジニアは、自分の思考活動とテスト対象の理解に応じて、テスト計画外のより多くのソフトウェアエラーを見つけることができます. ただし、探索的テストは通常​​、他のテスト方法の補足としてのみ使用され、より多くのテスト リソースを消費し、テスト エンジニアの経験に左右されるため、独立したテスト方法とは言えません。

H型

H モデルは、テスト活動を他の R&D プロセスから分離します. テスト活動は、図に示すように、テストの準備とテストの実行の 2 つの部分に分割され、テストの設計とテストの実行活動の定義を容易にします. テスト準備活動には、テスト要件分析、テスト計画、テスト設計、テストコーディング、テスト検証などが含まれます。テスト実行には、テスト実行、テストレポート、テスト結果分析、確認回帰テストなどが含まれます。

W モデルと同様に、H モデルは、ソフトウェア テスト活動が、ソフトウェア ライフ サイクル全体を通じて独立したソフトウェア生産プロセスであるべきであることを示しています.テスト活動は、できるだけ早く準備および実行する必要があります.テスト実行活動は、研究開発活動の対象となります。

アジャイル テスト モデル

顧客の視点からテストを強調する。
新機能の反復テストに焦点を当て、テスト フェーズを重視しない
できるだけ早くテストし、継続的にテストし、条件が満たされたときにテストする
継続的なフィードバックを
強調する 欠陥を発見することよりも、防止することが重要である

進化モデルとプロトタイプモデル

エボリューションモデルもプロトタイピング開発手法であり、ラピッドプロトタイピングモデルとは少し異なります。

ラピッド プロトタイピング モデルでは、プロトタイプの目的はユーザーの真のニーズを知ることであり、ニーズが満たされない場合、プロトタイプは破棄されます。
進化モデル開発プロセスは、初期モデルから最終的なソフトウェア製品までの段階的なプロセスです。

つまり、ラピッドプロトタイピングモデルは「使い捨て」のプロトタイピング方法であり、進化モデルは「段階的な」プロトタイピング方法です。

4.CMMI

参照: https://deepmind.t-salon.cc/article/6396 CMMI 能力成熟度モデルの 5 つのレベルと 22 のプロセス領域の詳細な説明、ソフトウェア エンジニアリングの基礎を
ブックマークして学習し、 CMM と CMM の関係を推奨します。 CMMI Fanfeng 情報 CMMI-DEV (開発ビュー)

CMMI の正式名称は Capability Maturity Model Integration、つまり Capability Maturity Model Integration です。CMMI は、CMM モデルの最新バージョンです。
CMMI の正式名称は Capability Maturity Model Integration. CMMI 認定には 5 つのレベルがあります。

CMMI1 レベルは完了レベル、CMMI2 レベルは管理レベル、CMMI3 レベルは定義レベル、CMMI4 レベルは量的管理レベル、CMMI5 レベルは最適化レベルです。

CMMI では、各 CMMI サブジェクト モデルには 2 つの表現があります。

段階的表現と継続的表現。
異なる表現のモデルは、異なる構造を持っています。連続表記は単一のプロセス領域の能力を強調し、ベースラインと測定結果の改善はプロセス領域の観点から検討されます.キーワードは「能力」であり、段階的表記は組織の成熟度を強調します
.集合的な視点では、「成熟度」というキーワードを使用して、組織全体のプロセスの成熟度段階を調べます。

CMMI プロセス領域

CMMI V1.3 には合計 22 のプロセス領域があり、プロセス領域 (PA): プロセス改善活動全体で重点的に取り組むべき、または改善すべき特定の側面の問題を記述し、プロセスごとに目標を設定し、それに従って実践します。目標。各プロセス領域には明確な目標 (目標) と実践 (実践) があり、目標と実践には以下が含まれます。

GG (Generic Goals)、中国語名は一般的な目標であり、GP (Generic Practices) に対応し、中国語名は一般的なプラクティスであり、能力次元に適用されるため、すべての重要なプロセス領域に適用できます。

SG (特定の目標)、中国語の名前は特定の目標であり、SP (特定の実践) に対応します。中国の名前は特定の実践であり、プロセス次元に適用され、特定の重要なプロセス領域にのみ適用できます。

CMMI レベル、プロセス領域、目的、および実践は、次のように関連しています。

CMMI実践領域

プラクティス ドメインは、CMMI (Capability Maturity Model Integration) フレームワークの重要な概念であり、特定の分野で効果的であることが証明されている一連の再利用可能な標準プラクティスを指します。
以前は「プロセス ドメイン」と呼ばれていたプラクティス ドメイン (構成管理など) は、現在は「プラクティス ドメイン」と呼ばれています。バージョン 2.0 では、25 の適用可能なプラクティス領域があります。以前のバージョンの CMMI モデルと同様に、「Domains of Practice」では、実践の意図を定義する主要な活動の要件と説明が紹介されています。

CMMI の実践領域は、一般実践領域と特定実践領域の 2 つのレベルに分けられます。一般的なプラクティス領域には、プロジェクト管理、エンジニアリング、プロセスおよび製品サポートが含まれます。これらのプラクティスは、組織全体のプロセス改善とプロジェクト管理をサポートするように設計されています。特定の実践領域は、さまざまな特別なニーズにより適切に対応するために、さまざまなビジネス分野や業界に従って作成されたいくつかの特定の実践です。

たとえば、ソフトウェア開発の分野では、CMMI の特定の実践分野には、要件管理、設計管理、テスト管理などが含まれます。これらのプラクティスは、ソフトウェア開発組織がより優れた要件管理、設計管理、およびテスト管理メカニズムを確立し、ソフトウェア開発の生産性を向上させ、ソフトウェア開発プロセスを最適化するのに役立ちます。

要約する

この一連のブログはソフトウェア エンジニアリングに関連しており、この記事はソフトウェア エンジニアリングの概要とソフトウェア プロセスの演習の第 1 部です。