システムアーキテクチャ設計専門スキル・ソフトウェアエンジニアリング

シリーズ記事の目次

システムアーキテクチャ設計の高度なスキル ・ソフトウェアアーキテクチャの概念、アーキテクチャスタイル、ABSD、アーキテクチャ再利用、DSSA (1) 【システムアーキテクト】 システムアーキテクチャ設計の高度なスキル ・システムの品質属性とアーキテクチャ評価 (2) 【
システムアーキテクト
】システムアーキテクチャ設計・ソフトウェア信頼性解析・設計(3) 【システムアーキテクチャ設計者】

1. ソフトウェアエンジニアリングのコンセプト★

ソフトウェア開発ライフサイクル:

ソフトウェア定義期間:実現可能性調査と詳細な要件分析プロセスが含まれます。タスクは、ソフトウェア開発プロジェクトが完了する必要がある全体的な目標を決定することであり、問​​題定義、実現可能性調査、要件分析などに分けることができます。
ソフトウェア開発期間：ソフトウェアの設計と実装を指し、概要設計、詳細設計、コーディング、テストなどに分けられます。
ソフトウェア運用保守：ソフトウェア製品を利用者に引き渡すことを指します。

ソフトウェア システムのドキュメント:

ソフトウェア システム ドキュメントは、ユーザー ドキュメントとシステム ドキュメントの2 つのカテゴリに分類できます。ユーザー ドキュメントでは主にシステムの機能と使用法について説明し、これらの機能の実装方法は関係ありません。システム ドキュメントでは、システムの設計、実装、およびテストのさまざまな側面について説明します。

ソフトウェアエンジニアリングプロセスとは、ソフトウェア製品を実現するための以下の4つの活動（PDCA）を指します。

P (計画) - ソフトウェア仕様: ソフトウェアの機能とその実行時の制限を指定します。
D(Do) - ソフトウェア開発: 仕様を満たすソフトウェアを開発します。
C (チェック) - ソフトウェアの確認: 開発したソフトウェアがユーザーのニーズを満たしていることを確認します。
A (アクション) - ソフトウェアの進化: ソフトウェアは、新しい顧客のニーズを満たすために運用中に継続的に改善されます。

ソフトウェア システム ツールは通常、ソフトウェア プロセス アクティビティに応じて次のソフトウェア ツールに分類できます。

ソフトウェア開発ツール: 要件分析ツール、設計ツール、コーディングおよびデバッグ ツール、テスト ツールなど。
ソフトウェア保守ツール：バージョン管理ツール、文書分析ツール、開発情報ベースツール、リバースエンジニアリングツール、リエンジニアリングツール。
ソフトウェア管理およびソフトウェア サポート ツール: プロジェクト管理ツール、構成管理ツール、ソフトウェア評価ツール、およびソフトウェア開発ツールの評価と選択。

ソフトウェア設計には、
データ設計、アーキテクチャ（システム構造）設計、ヒューマン・コンピュータ・インターフェース（インターフェース）設計、プロセス設計の4つの作業があります。

1.1 ソフトウェア危機

2. ソフトウェア機能成熟度モデル

ソフトウェアの機能成熟度モデル (CMM)

能力レベル	特徴	主要なプロセス領域
初期レベル	ソフトウェア プロセスは、明確に定義された手順がほとんどなく、組織化されておらず、時には混沌としていることを特徴とし、プロジェクトの成功は個人の努力と英雄的な中心人物の役割に完全に依存しています。
再現可能なレベル	基本的なプロジェクト管理プロセスと実践方法は、プロジェクトのコスト、スケジュール、機能を追跡するために確立されており、同様のプロジェクトで以前の成功を繰り返すために必要なプロセス規律が整備されています。	ソフトウェア構成管理、ソフトウェア品質保証、ソフトウェア下請け管理、ソフトウェアプロジェクト追跡および監督、ソフトウェアプロジェクト計画、ソフトウェア要件管理
レベルが定義されています	管理とエンジニアリングの両方におけるソフトウェア プロセスは文書化され、標準化され、ソフトウェア開発組織全体の標準ソフトウェア プロセスに統合されています。すべてのプロジェクトでは、実際の条件に応じて修正された標準ソフトウェア プロセスを使用してソフトウェアを開発および保守します。	ピアレビュー、グループ間調整、ソフトウェア製品エンジニアリング、統合ソフトウェア管理、トレーニング概要、組織プロセス定義、組織プロセスの焦点
すでに管理されています	ソフトウェアのプロセスと製品の品質に関する詳細な指標が開発されます。ソフトウェアプロセスと製品品質を定量的に理解し、管理します。	ソフトウェアの品質管理と定量的なプロセス管理
最適化レベル	定量的な分析が強化され、プロセス品質からのフィードバックや新しいコンセプトや新しいテクノロジーからのフィードバックを通じてプロセスを継続的に改善できます。	プロセス変更管理、技術変更管理、および欠陥防止

Capability Maturity Model Integration for Software (CMMI)
ステージ モデル CMMI は CMM に基づいて開発され、組織の成熟度に重点を置いています。

能力レベル	特徴	主要なプロセス領域
初期レベル	プロセスが予測不能で制御ができない
すでに管理されています	プロセスはプロジェクトに貢献します	要件管理、プロジェクト計画、構成管理、プロジェクトの監督と制御、サプライヤー契約管理、測定と分析、プロセスと製品の品質保証
レベルが定義されています	プロセスは組織に役立つ	要件開発、技術ソリューション、製品統合、検証、組織プロセスの焦点の検証、組織プロセス定義、組織トレーニング、統合プロジェクト管理、リスク管理、統合チーム、意思決定分析とソリューション、組織統合環境
定量的な管理	プロセスは測定され、制御されます	組織プロセスのパフォーマンス、定量的なプロジェクト管理
最適化レベル	プロセスの改善と最適化に重点を置く	組織レベルの改革と実行、原因と結果の分析と解決策

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

3.1 ウォーターフォールモデル

ウォーターフォールモデル（SDLC）はライフサイクル手法とも呼ばれ、ライフサイクル手法の中で最もよく使われる開発モデルで、ソフトウェア開発は一般に実現可能性分析（計画）、要件分析、ソフトウェア設計（概要設計、コーディング（単体テストを含む）、テスト、運用保守などの各段階は、上から下へ一定の順序が定められており、滝のように段階的に流れ落ちていきます。図に示すように:

ウォーターフォールモデルの特徴:

• 前の開発アクティビティからのこのアクティビティの作業オブジェクトを入力として受け入れます。
• この入力を使用して、アクティビティによって実行されるべき作業を実装します。
• このアクティビティの作業結果は、出力として次の開発アクティビティに渡されます。
• このアクティビティの実施結果を確認します。作業結果が確認できた場合は次の開発作業を続行し、作業結果が確認できなかった場合は、前またはさらに前の作業に戻ります。複数のステージ間の繰り返しを最小限に抑えます。比較的少額の費用でソフトウェアを開発できる

ウォーターフォール モデルは、大規模なソフトウェア開発プロセスにおける人員の組織と管理に役立ち、ソフトウェア開発手法とツールの研究と使用にも役立ち、その結果、大規模なソフトウェア プロジェクト開発の品質と効率が向上します。ただし、ソフトウェア開発の実践では、上記のアクティビティが完全なトップダウンではなく、線形図で示されていることが示されているため、ウォーターフォール モデルには重大な欠陥があります。

• 開発モデルは線形であるため、開発結果がテストされていない場合、ユーザーはソフトウェアの効果を確認できません。このように、ソフトウェアとユーザーの間の時間間隔が長くなり、一定のリスクも増加します。
• ソフトウェア開発の初期段階で発見されなかったエラーがその後の開発活動に波及すると、エラーが拡大し、ソフトウェアプロジェクト全体の失敗につながる可能性があります。
• ソフトウェア要件の分析段階では、ユーザーのニーズをすべて完全に判断することは困難、または不可能です。

3.2 試作モデル

プロトタイピング モデルは主に、要件を事前に完全に定義できないソフトウェア開発を目的としています。プロトタイプの迅速な開発に基づいて、プロトタイプは改善され、プロトタイプの新しいバージョンが取得されます。ユーザーがプロトタイプを呼び出すプロセス中、このプロセスは最終ソフトウェア製品に進化するまで繰り返されます。

プロトタイプ手法では、ユーザーのニーズを一度に完全かつ正確に提示することが難しい場合、プロトタイプには次の特性が必要であると考えられます。

• 実用的かつ実現可能。
• 最終システムの基本特性を備えています。
• 構造は便利で速く、コストは低いです。プロトタイプ方式の特徴は、ユーザーのニーズに動的に対応し、徐々に取り込んでいく点にあります。

プロトタイピング方法/モデルについて:

ソフトウェア プロトタイプは、提案された新製品の部分的な実装です。プロトタイプを確立する主な目的は、製品開発の初期段階で不確実な要件の問題を解決することです。その目的は、要件を明確にして改善し、設計オプションを検討し、最終製品に発展します。プロトタイプ モデルは、要件が十分に明確ではないプロジェクトに適しています。

プロトタイプを分類する方法はたくさんあります。プロトタイプが機能を実装するかどうか、ソフトウェア プロトタイプは水平プロトタイプと垂直プロトタイプの2 つのタイプに分類できます。水平プロトタイプは、動作プロトタイプとも呼ばれ、予想されるシステムの特定の動作を調査し、要件を洗練するという目的を達成するために使用されます。水平プロトタイプは、多くの場合、実際に実装することなく、単なる機能のナビゲーションにすぎません。水平プロトタイプは主にインターフェースで使用されます。垂直プロトタイプは構造化プロトタイプとも呼ばれ、機能の一部を実装します。垂直プロトタイピングは、主に複雑なアルゴリズムの実装で使用されます。

プロトタイプの最終結果の観点から、ソフトウェア プロトタイプは、使い捨てプロトタイプと進化型プロトタイプに分類できます。廃棄されたプロトタイプは探索的プロトタイプとも呼ばれ、期待された目的が達成された後にプロトタイプ自体が放棄されることを意味します。使い捨てプロトタイプは主に、需要の不確実性、曖昧さ、不完全性、曖昧さなどを解決するために使用されます。進化的プロトタイプは、増分製品を開発するための基礎を提供し、スパイラル モデルの一部であり、オブジェクト指向ソフトウェア開発プロセスの一部です。進化的プロトタイプは主に、アップグレードと最適化が容易でなければならないプロジェクトで使用され、Web プロジェクトに適しています。

文献によっては、プロトタイプを実験型、探索型、進化型に分類しているものもあります。探索的プロトタイピングの目的は、ターゲット システムの要件を明確にし、必要な機能を決定し、複数のソリューションの実現可能性を調査することです。実験用プロトタイプを大規模な開発や実装に使用する前に、計画が適切かどうか、仕様が信頼できるかどうかを評価します。進化プロトタイピングの目的は仕様の向上ではなく、変更しやすいシステムを構築することであり、プロトタイプを改良していく過程で、プロトタイプを徐々に最終システムに進化させていきます。

文献によっては、プロトタイプを使い捨てプロトタイプ、進化的プロトタイプ、増分プロトタイプに分類しているものもあります。

プロトタイピング方法は、ユーザーがニーズを判断するための明確なコンテンツを持っていない場合に適しています。まず、与えられ分析された要件に基づいて独自のモデルを確立しますが、これは変更可能なモデルです（ライフサイクル手法では、要件が分析されて文書化された後は、通常、それ以上の変更は必要ありません）。

ソフトウェア開発の各段階で、モデルが修正されるまで関連情報が相互にフィードバックされ、モデルが徐々に完成度を高めていきます。このプロセスでは、ユーザーの参加と意思決定が強化され、最終結果はユーザーの要件により適したものになります。

この種のプロトタイピング テクノロジは、使い捨て、進化的、増分という 3 つのカテゴリに分類できます。このプロトタイプ手法の成功と効率の鍵は、モデルの確立とモデリングの速度にあります。

3.3 インクリメンタルモデル

インクリメンタル モデルは、ウォーターフォール モデルの基本コンポーネント (反復アプリケーション) とプロトタイプ実装の反復特性を組み合わせます。インクリメンタル モデルでは、時間の経過とともに変化する線形シーケンスが使用され、各線形シーケンスがソフトウェアのリリース可能な「増分」を生成します。インクリメンタル モデルを使用する場合、多くの場合、最初のインクリメントがコア製品になります。つまり、最初のインクリメントは基本要件を実装しますが、多くの追加機能はまだリリースされていません。各増分に対する顧客の使用と評価は、次の増分でリリースされる新機能として機能します。このプロセスは、段階的にリリースされるたびに、最終的な研磨された製品が製造されるまで繰り返されます。

増分モデルは、各増分が運用可能な製品をリリースすることを強調します。図に示すように:

プロトタイプ実装モデルやその他の進化的手法と同様、増分モデルは本質的に反復的です。ただし、プロトタイプの実装とは異なり、増分モデルでは、各増分が運用可能な製品をリリースすることが強調されます。初期の増分は最終製品の「取り外し可能な」バージョンですが、ユーザーにサービスを提供し、ユーザー評価用のプラットフォームを提供する機能を提供します。インクリメンタルモデルの特徴は、インクリメンタルパッケージの概念を導入していることであり、すべての要件のリリースを待つ必要はなく、特定の要件のインクリメンタルパッケージがリリースされていれば開発を進めることができます。特定の増分パッケージを顧客のニーズにさらに適合させ、変更する必要がある場合でも、増分パッケージが十分に小さい限り、プロジェクト全体への影響は耐えられます。

インクリメンタルモデルのメリットは、人員配置が柔軟であり、最初に多くの人的資源を投入する必要がなく、主力製品の人気が高ければ、次の増産に向けて人員を追加できることです。スタッフが設定された期限内に製品を完成させることができない場合、コア製品を最初にリリースする方法が提供され、一部の機能が最初に顧客にリリースされ、顧客の精神安定剤として機能します。さらに、増分により、技術的リスクの計画的な管理が可能になります。インクリメンタル モデルの欠点は、インクリメンタル パッケージ間に交差があり、それをうまく処理できない場合、包括的なシステム分析を行う必要があり、モジュールをうまく分割できないことです。インクリメンタルモデルは、要件が頻繁に変化するソフトウェア開発プロセスに機能改良と個別開発の手法を適用します。

3.4 スパイラルモデル

スパイラル モデルは、ウォーターフォール モデルとプロトタイピング (進化) モデルを組み合わせ、両方の利点を組み合わせ、リスク分析を追加します。プロトタイプをベースにして、スパイラルに沿って内側から外側に回転し、各回転ごとに計画、リスク分析、実装エンジニアリング、顧客評価などの活動が必要となり、新しいバージョンのプロトタイプが開発されます。

スパイラル モデルはリスク分析を重視しており、大規模で複雑な高リスク システムに特に適しています。いくつかのスパイラルプロセスを経て、図に示すような最終的なシステムが得られます。 (プロジェクトの開始時には要件が曖昧であることがよくありますが、プロジェクトが進行するにつれて徐々に明確になります。つまり、要件は徐々に詳細化されます。) ）

3.5Vモデル

開発モデルでは、状況を改善するためにテストが後付けで使用されることがよくありますが、テストを中心とした開発モデル、つまり V モデルもあります。V モデルは、ソフトウェア業界では漠然とした認識しか受けていません。V モデルでは、図に示すように、テストは後で補う行為ではなく、開発プロセスと同じくらい重要なプロセスであると主張しています。

V モデルは最も代表的なテスト モデルであり、ウォーターフォール モデルの変形であり、ウォーターフォール モデルに基づいてテストを強化し、テスト活動と分析および設計の関係を反映します。V モデルでは、左側の下降部分が開発プロセスの段階、右側の上昇部分がテスト プロセスの段階です。V モデルのソフトウェア テスト戦略には、低レベル テストと高レベル テストの両方が含まれており、低レベル テストはソース コードの正確性を対象とし、高レベル テストはシステム全体をユーザーのニーズを満たすためのものです。V モデルにはいくつかの制限があり、テスト プロセスは要件分析、概要設計、詳細設計、コーディング後の段階としてのみ認識されます。テストが全体を通して機能するようにします。

V モデルは、ソフトウェア開発のコラボレーションとスピードを重視し、ソフトウェアの実装と検証を有機的に組み合わせ、高いソフトウェア品質を確保しながら開発サイクルを短縮します。V モデルはエンタープライズレベルのソフトウェア開発に適しており、ソフトウェア開発プロセスの特徴と本質をより明確に示します。

V モデルの価値は、テスト プロセスに存在するさまざまなレベルを非常に明確に示し、これらのテスト フェーズと開発プロセスの段階との対応を明確に説明していることです。

• 単体テストの主な目的は、コーディング プロセス中に存在する可能性のあるさまざまなエラーを対象にすることです。例: ユーザー入力検証中の境界値のエラー。
• 統合テストの主な目的は、詳細設計で起こり得る問題をターゲットにすること、特に各ユニットと他のプログラム部分の間のインターフェイスで起こり得るエラーをチェックすることです。
• システムテストでは、概要設計を中心に、システム全体が有効に動作するかどうかを確認します。例: 製品設定で期待される高いパフォーマンスが達成されるかどうか。
• 受け入れテストは通常​​、製品がユーザーのビジネス ニーズを真に満たすことができることを確認するために、ビジネスの専門家またはユーザーによって実施されます。

反復と増分の概念

3.6 噴水モデル

ファウンテン モデルは、ソフトウェアの再利用とライフ サイクルにおける複数の開発アクティビティの統合をサポートします。主にオブジェクト指向開発手法をサポートします。ユーザーのニーズとオブジェクトによって駆動されるモデルです。「噴水」という言葉自体が、反復的でギャップのない性質を体現しています。システムの特定の部分は、繰り返しのたびに進化するシステムに関連する機能が追加されて、何度も作り直されることがよくあります。いわゆるギャップなしとは、図に示すように、開発活動において、分析、設計、コーディングの間に明確な境界がないことを意味します。

3.7 CBSDコンポーネントベースモデル（コンポーネントアセンブリモデル/コンポーネントベースのソフトウェア開発）

コンポーネント (Component) は、再利用可能な価値と比較的独立した機能を備えたソフトウェア単位です。コンポーネントベースのソフトウェア開発 (CBSD) モデルは、モジュール化手法を使用してシステム全体をモジュール化し、特定のコンポーネント モデルのサポートを受けて、コンポーネント ライブラリ内の 1 つまたは複数のソフトウェア コンポーネントを組み合わせ手段によって再利用します。高効率と高品質を実現します。

コンポーネントベースの開発モデルには、スパイラル モデルの多くの特徴が組み込まれており、本質的に進化的であり、開発プロセスは反復的です。コンポーネントベースの開発モデルは、ソフトウェア要件の分析と定義、アーキテクチャ設計、コンポーネント ライブラリの確立 (コンポーネント ライブラリにはコンポーネントの取得とコンポーネントの管理が含まれます)、アプリケーション ソフトウェアの構築、テストとリリースの 5 つの段階で構成されます。図に示すように:

CBSE コンポーネントには次の特性が必要です。

• アセンブリ可能性: すべての外部対話は、公的に定義されたインターフェイスを通じて発生する必要があります。
• 導入可能性: コンポーネントは常にバイナリ形式であり、プラットフォーム上で独立したエンティティとして実行できます。
• ドキュメント: ユーザーはコンポーネントが要件を満たしているかどうかをドキュメントに基づいて判断します。
• 独立性: 他の特別なコンポーネントを使用せずに組み立てて展開できます。
• 標準化: 特定の規格に準拠したコンポーネント モデル。

CBSE コンポーネントの組み立て順序:

• 順次アセンブリ: 既存のコンポーネントを順番に呼び出します。2 つの既存のコンポーネントを使用して、新しいコンポーネントを作成できます。
• 階層アセンブリ: 呼び出されるコンポーネントの「提供された」インターフェイスは、呼び出し側コンポーネントの「要求」インターフェイスと互換性がある必要があります。
• オーバーレイ アセンブリ: 複数のコンポーネントを結合して新しいコンポーネントを形成します。新しいコンポーネントは、元のコンポーネントの機能を統合し、外部世界への新しいインターフェイスを提供します。

重要なソフトウェア技術およびツールとして、コンポーネントは大幅に開発されており、これらの新しい技術標準およびツールには、Microsoft の DCOM/COM、Sun の EJB、OMG の CORBA などが含まれます。コンポーネントベースの開発活動は、コンポーネントの候補を特定することから始まります。既存のコンポーネント ライブラリを検索して、必要なコンポーネントが既に存在するかどうかを確認します。既に存在する場合はコンポーネント ライブラリから抽出して再利用し、存在しない場合はオブジェクトを使用します。指向性のあるメソッドを開発します。抽出されたコンポーネントが構文チェックとセマンティック チェックに合格した後、これらのコンポーネントはグルー コードを通じて組み立てられ、システムが実装されます。このプロセスは反復的です。

コンポーネントベース開発手法では、ソフトウェア開発をゼロから開始する必要がなくなり、開発プロセスはコンポーネントの組み立てプロセスであり、保守プロセスはコンポーネントのアップグレード、交換、拡張のプロセスであり、コンポーネントの組み立てモデルが次のことにつながるという利点があります。ソフトウェアの再利用と改善ソフトウェア開発の効率が向上します。コンポーネントは一方の当事者によって定義され、別の当事者によって実装され、その後、使用するために第三者に提供されます。コンポーネント アセンブリ モデルにより、複数のプロジェクトを同時に開発できるため、コストが削減され、改善されます。保守性が向上し、ソフトウェア製品を段階的に提出できるようになります。
欠点は、カスタマイズされたアセンブリ構造標準を使用しているため、普遍的なアセンブリ構造標準が欠如しており、導入にはリスクがあり、再利用性とソフトウェア効率を調整するのが容易ではなく、有能で経験豊富なアナリストと開発者が必要であることです。開発者が関与できない場合、顧客満足度は低くなり、コンポーネントに過度に依存し、コンポーネント ライブラリの品質が製品の品質に影響を及ぼします。

3.8 アジャイルモデル

開発マニフェスト:プロセスやツールよりも個人と対話、徹底的なドキュメントよりも動作するソフトウェア、契約交渉よりも顧客とのコラボレーション、計画に従うよりも変更への対応。

アジャイル開発手法

アジャイル手法は他の手法と次の 2 つの特徴で区別されます。 (1) 「プリセット」ではなく「適応型」
です。（２） 「プロセス重視」ではなく「人重視」である。アジャイル開発の中核となる考え方: (1) アジャイル開発は適応的であり、予測可能ではありません。変化を受け入れ、変化に適応します。(2) アジャイル開発はプロセス指向ではなく、人指向です。人間の特性を引き出す。(3)反復的かつ段階的な開発プロセス。プロトタイプ開発の考え方に基づいて、インクリメンタル開発に代わる手法が使用され、リリースバージョンは小型化されます。

XP エクストリーム プログラミング

XP は、軽量 (アジャイル)、効率的、低リスク、柔軟、予測可能、科学的で楽しいソフトウェア開発方法です。他の方法論と比較した最大の違いは次のとおりです。

(1) コード駆動ルールの場合、重要なドキュメントはソース コードです。
(2) 具体的かつ継続的なフィードバック情報を、より早く、より短いサイクルで提供する。
(3) 反復的に計画を立てます。まず最初にマスター プランを迅速に作成し、プロジェクト開発プロセス全体を通じてそれを発展させます。
(4) 自動テスト プログラムを利用して開発の進行状況を監視し、欠陥を早期に発見します。
(5) 口頭によるコミュニケーション、テスト、およびコミュニケーションのためのソース プログラムに依存します。
(6) 継続的に進化するデザインを提唱する。
(7) 開発チーム内の緊密な協力に依存します。
(8) プログラマーの短期的な利益とプロジェクトの長期的な利益の間で可能な限りバランスをとるように努めてください。

4 つの値:

• コミュニケーション、対面コミュニケーションの強化
• シンプルでデザインしすぎない
• フィードバック、タイムリーなフィードバック
• 勇気、変化を受け入れる勇気

XP は、複雑な開発プロセスを比較的単純なサイクルに分割する、スパイラルに近い開発手法です。積極的なコミュニケーション、フィードバック、その他の一連の方法を通じて、開発者と顧客は開発の進捗状況を非常に明確に把握でき、問題を次のように変更します。解決すべき問題や潜在的な問題などを把握し、実際の状況に応じて開発プロセスをタイムリーに調整します。

XP では、将来バグが発生する可能性を最小限に抑えるために、最初にテストすることを推奨しています。

XP は、厳格なコスト管理を行っている一部の企業で非常に効果的に使用されています。

結晶法

Crystal シリーズ方式は、XP 方式と同様に人間中心の哲学を持っていますが、実際には異なります。目的は、「モビリティ」を促進し、それぞれが独自の役割、プロセス モデル、作業成果物、実践方法を持つ共通の核となる要素を含むアプローチを開発することです。

クリスタル メソッドは、最小限の規律で成功を収める方法を探求し、生産性と操作の容易さのバランスを実現します。

オープンソース

オープンソース: プログラム開発者は地理的に広く分散しています [他の方法では集中オフィスを重視しています]。

並行して法律についての議論を行う

SCRUM は反復的で増分的なプロセスです。期間 (30 日など) ごとに 1 回の反復を「スプリント」と呼び、要件の優先順位に従って製品が実装されます。自己組織化された自律的なチームが製品を並行して段階的に実装します。

SCRUM: プロジェクト管理に焦点を当てた、明確に定義された反復可能な方法論的プロセス。。

機能駆動開発 (FDD)

機能駆動開発 (FDD) は、反復的な開発モデルです。効果的なソフトウェア開発には、人材、プロセス、テクノロジーという 3 つの要素が必要であると考えられています。全体的なオブジェクト モデルの開発、機能リストの構築、機能開発の計画、機能設計、および機能構築の 5 つのコア プロセスがあります。プロジェクトの 6 つの主要な役割 (プロジェクト マネージャー、チーフ アーキテクト、開発マネージャー、リード プログラマー、プログラマー、ドメイン エキスパート) が定義されています。

関数駆動開発 (FDD): プログラミング開発者は、リード プログラマと「クラス」プログラマの 2 つのカテゴリに分類されます。

ASD法

ASD メソッド: その中心となるのは、推測、コラボレーション、学習という3 つの非線形で重複する開発フェーズです。

動的システム開発手法

動的システム開発手法 (DSDM) : __ ビジネスを中心とすることを提唱します。

3.9 RADモデル（迅速なアプリケーション開発モデル）

Rapid Application Development (RAD) モデルは、非常に短い開発サイクルを重視した増分ソフトウェア開発プロセス モデルです。RAD モデルは、ウォーターフォール モデルの「高速」バリアントであり、コンポーネント ベースの構築方法を使用して、再利用可能なコンポーネントを広範囲に使用することで迅速な開発を実現します。要件がよく理解され、プロジェクトの範囲が制限されている場合は、このモデルを使用して完全に機能する「情報システム」を迅速に作成できます。このプロセスはビジネス モデリングから始まり、データ モデリング、プロセス モデリング、アプリケーションの生成、テスト、反復が続きます。図に示すように、ウォーターフォール モデルと CBSD (コンポーネントベース ソフトウェア開発) の包括的な開発モデル:

RAD モデルの各アクティビティ期間で完了するタスクは次のとおりです。

• ビジネス モデリング: ビジネス プロセスを推進する情報は何ですか? どのような情報が生成されるのでしょうか? 誰がそれを生成しますか? 情報の流れはどこへ行くのでしょうか？誰によって？これはデータ フロー図で補足できます。
• データ モデリング: ビジネス プロセスのデータ フローをサポートするために、データ オブジェクトのコレクションを見つけ、データ オブジェクトの属性を定義し、他のデータ オブジェクトとの関係でデータ モデルを形成します。これは ER 図で補完できます。
• プロセス モデリング: データ オブジェクトが情報フロー内のさまざまなビジネス機能を完了できるようにします。データ オブジェクトの追加、変更、削除、検索を記述するプロセスを作成します。つまり、データ フロー図内の処理ボックスを調整します。
• アプリケーションの生成: 第 4 世代言語 (4GL) を使用して処理プログラムを作成し、既存のコンポーネントを再利用または新しい再利用可能なコンポーネントを作成し、環境によって提供されるツールを使用してアプリケーション システム全体を自動的に生成および構築します。
• テストと配信、再利用が多いため、通常は全体的なテストのみが行われますが、新しく作成されたコンポーネントもテストする必要があります。

ウォーターフォール モデルと比較して、RAD モデルはソフトウェアの作成に従来の第 3 世代プログラミング言語を使用するのではなく、コンポーネントベースの開発手法を採用し、既存のプログラム構造を再利用する（可能であれば）か、再利用可能なコンポーネントを使用するか、再利用可能なコンポーネントを作成します。必要に応じて。すべての場合において、ソフトウェアの作成を支援するために自動ツールが使用されました。RAD モデル プロジェクトに課せられる時間制約には、「スケーラブルな範囲」が必要であることは明らかです。ビジネスをモジュール化して、各主要機能を 3 か月以内に完了できる場合は、RAD の候補となります。それぞれの主要な機能は個別の RAD グループによって実装でき、最終的に統合して全体を形成できます。

RAD モデルは、再利用可能なコンポーネントを広範囲に使用することで開発をスピードアップし、特に情報システムの開発に効果的です。しかし、他のすべてのソフトウェア プロセス モデルと同様、RAD アプローチにも次のような欠陥があります。

• すべてのアプリケーションが RAD に適しているわけではありません。RAD モデルには、モジュール化に対する比較的高い要件があります。モジュール化できない機能がある場合、RAD の構築に必要なコンポーネントに問題が発生します。高性能が指標の場合、インターフェースを調整して指標をシステムに適合させる必要があります。コンポーネントが勝つ場合もありますが、RAD アプローチが機能しない場合もあります。
• 開発者と顧客は非常に短期間で一連の需要分析を完了する必要があり、どちらかの協力が適切でないと RAD プロジェクトの失敗につながります。
• RAD は情報システム開発にのみ使用でき、技術的なリスクが高い状況には適していません。これは、新しいアプリケーションで多くの新しいテクノロジが使用されている場合、または新しいソフトウェアが既存のコンピュータ プログラムとの高レベルの相互運用性を必要とする場合に発生します。

3.10 統合プロセスモデル (RUP/UP)

RUPの特徴

(1)ユースケース駆動: 要件分析、設計、実装、テストなどの活動はすべてユースケースによって駆動されます。
(2)アーキテクチャ中心: システム全体の組織とグローバルな制御、通信プロトコルなどを含みます。これは多次元構造であり、複数のビュー (4 + 1 ビュー) を使用して説明します。
(3)反復と増分: プロジェクト開発全体を複数の反復プロセスに分割します。各反復では、システム要件の一部のみが考慮され、分析、設計、実装、テスト、展開などのプロセスが実行されます。各反復は、完成した部分に基づいて実行され、いくつかの新しい機能実装が追加されます。これは、最終プロジェクトが完了するまで続きます。

RUPには4つのフェーズがあります

ソフトウェアの統一開発プロセスでは、工程順に初期段階、改良段階、構築段階、納品段階の4つの開発段階が定義されており、このうち構築段階で生成される主なドキュメントは設計モデルです。

• 初期段階: プロジェクトのブループリント文書 (コア要件、主要な機能、主な制約)、ユースケースモデル、プロジェクト計画

• 洗練段階: アーキテクチャ設計を完了し、高リスク要素を排除します

• 構築フェーズ：UMLモデル、テストケース

• 提供フェーズ: 実行可能なソフトウェア製品、ユーザー マニュアル、ユーザー サポート プラン。

RUP には 9 つのコア ワークフローがあります

RUP のワークフローは、コア ワークフローとコア サポート ワークフローの 2 つの部分に分かれています。コア ワークフロー (プロジェクト内のプロセス) には、ビジネス要件のモデリング、分析と設計、実装、テスト、展開が含まれ、コア サポート ワークフロー (組織内のプロセス) には、環境、プロジェクト管理、構成、および変更管理が含まれます。

RUP ソフトウェア開発ライフ サイクルは2 次元のソフトウェア開発モデルであり、 RUP には次の9 つのコア ワークフローがあります。

• ビジネスモデリング：開発対象のシステムが置かれている組織とその業務内容を理解し、参加者全員が開発対象のシステムが置かれている組織について共通理解を持ち、開発対象のシステムが企業に与える影響を評価します。組織。
• 要件: システム機能とユーザー インターフェイスを定義し、顧客にシステムの機能を知らせ、開発者がシステム要件を理解できるようにし、プロジェクトの予算と計画の基礎を提供します。
• 分析・設計: 需要分析の結果を分析・設計モデルに変換します。
• 実装: 設計モデルを実装結果に変換し、開発されたコードに対して単体テストを実行し、さまざまな実装者によって開発されたモジュールを実行可能システムに統合します。
• テスト: サブシステム間の相互作用と統合をチェックし、すべての要件が正しく実装されているかどうかを検証し、ソフトウェア品質で発見された欠陥をアーカイブし、ソフトウェア品質を向上させるための提案を行います。
• 導入: ソフトウェアのパッケージ化、配布、インストール、古いシステムのアップグレード、ユーザーと営業スタッフのトレーニング、技術サポートの提供。
• 構成および変更管理: システム開発中に生成されるすべての成果物の整合性と一貫性を追跡および維持します。
• プロジェクトマネジメント：ソフトウェア開発プロジェクトの計画、人員配置、実行、モニタリング等を指導し、リスク管理の枠組みを提供します。
• 環境: ソフトウェア開発組織にソフトウェア開発環境を提供します。つまり、プロセス管理とツールのサポートを提供します。

4. リバースエンジニアリング

リバースエンジニアリングは、既存のプログラムからデータ構造、アーキテクチャ、プログラミング情報を抽出することを特徴としています。

そのプロセスは、既存システム→リバースエンジニアリング→新しい要件の検討→フォワードエンジニアリング→新しいシステムです。

ソフトウェアのリバース エンジニアリングは、設計を復元し、既存のプログラムからデータ、アーキテクチャ、およびプロセス設計情報を抽出するプロセスです。リバース エンジニアリングの完全性は、特定の抽象化レベルで提供される詳細レベルによって説明できますが、ほとんどの場合、抽象化レベルが高くなるほど完全性は低くなります。

ドメインレベルの抽象化レベルは最も高い完全性と最も低い完全性であり、実装レベルの抽象化レベルは最も低い完全性と最も高い完全性です。

リバース エンジニアリングに関連する概念には、リファクタリング、デザイン リカバリ、リエンジニアリング、フォワード エンジニアリングが含まれます。

• 再構築とは、同じ抽象レベルでシステム記述形式を変換することを指します。
• 設計リカバリとは、既存のプログラムからデータ設計、全体構造設計、およびプロセス設計に関する情報を抽象化するためのツールの使用を指します。
• リバース エンジニアリングは、プログラムを分析し、ソース コードよりも高い抽象レベルでプログラムの表現を確立しようとするプロセスであり、設計を復元するプロセスです。
• フォワード エンジニアリングとは、既存のシステムから設計情報を回復するだけでなく、その情報を使用して既存のシステムを変更または再構築し、全体の品質を向上させることも指します。
• リエンジニアリングは、既存のシステムを再開発するプロセスであり、リバース エンジニアリング、新しい要件の検討、フォワード エンジニアリングの 3 つのステップが含まれます。

情報を回復するためのリバース エンジニアリングの方法:

方法	輸出情報
ユーザーガイドによる検索および変換方法	実装レベル、構造レベル
変革的な手法	実装レベル、構造レベル、機能レベル
ドメイン知識ベースの手法	機能レベル、ドメインレベル
ユーザーガイドによる検索および変換方法	鉛板回収方法実装レベル、構造レベル

5. 要件エンジニアリング

2.1 ソフトウェア要件の階層

2.2 要件エンジニアリング

ソフトウェア要件とは、機能、動作、パフォーマンス、設計制約などの観点からシステムに対するユーザーの期待を指します。

要件エンジニアリング (RE) とは、適切なツールと表記法を使用して、開発対象のシステム、その動作特性、および関連する制約を体系的に記述するために、実証済みの効果的な原理と方法を適用することを指します。

要求エンジニアリングは、図に示すように、要求の取得、要求の分析、要求仕様の作成 (または要求の文書化)、要求の確認と検証、および要求の管理の 5 つの段階で構成されます。

ソフトウェア要件仕様 (SRS)
SRS には、特に機能。制約には、設計制約とプロセス制約が含まれます。承認された SRS は、要件開発と要件管理の間の橋渡しとなります

要件管理
要件管理は、変更管理、バージョン管理、要件追跡、その他のアクティビティを含む、システム要件を変更、理解、制御するプロセスです。

2.5 要件の開発 (メインライン、目標)

2.5.1 要件の分類

• 要件の分類

(1)ビジネス ニーズ: ビジネス ニーズは、企業または顧客のシステムに対する高レベルの目標要件を反映しており、通常、プロジェクト投資家、製品を購入する顧客、顧客部門のマネージャー、マーケティング部門または製品企画部門などから発生します。ビジネス要件によって、プロジェクトのビューと範囲が決まります。

(2)ユーザー要件: ユーザー要件は、ユーザーの特定の目標、またはユーザーがシステムに完了させる必要があるタスクを記述します。つまり、ユーザー要件は、ユーザーがシステムで何ができるかを記述します。ユーザーの利用シーン（シナリオ）を整理し、ユーザーのニーズを確立するために、ユーザーインタビューやアンケートが一般的に行われます。

(3)システム要件: システム要件は、機能要件、非機能要件、設計上の制約を含む、システムの観点からソフトウェア要件を記述します。

• 品質機能の展開 QFD

ソフトウェアエンジニアリングプロセスにおいてユーザーの満足度を最大化することを目的として、ユーザー要件をソフトウェア要件に変換するテクノロジーです。この目標を達成するために、QFD はソフトウェア要件を通常の要件、予想される要件、予期しない要件の 3 つのカテゴリに分類します。

(1)基本ニーズ：通常のニーズとも呼ばれ、ユーザーがシステムが実現すべきと考える機能や性能であり、実装される機能や性能が多ければ多いほどユーザーの満足度が高くなります。

(2)期待される要件：利用者は、システムが持つべき機能や性能を当然のことと思っているが、自分が求める機能や性能の要件を正確に説明することができない。期待が満たされないと、ユーザーは不満を感じます。

(3)予期せぬ要件: 予期せぬ要件は、エキサイティングな要件とも呼ばれ、ユーザー要件の範囲外の機能や性能です (ただし、通常はソフトウェア開発者が喜んでシステムに提供する技術的特徴)。実現しても実現されず、購入決定にも影響しません。

2.5.2 要件の取得

方法	特徴
情報を集める	システム開発に役立つシステム関連の情報を収集します。
歴史的文書を読む	データベースの情報を収集するのに役立ちます。
ユーザーインタビュー	1 ～ 1-3、代表的なユーザー、主観的な考えを理解する、良好なインタラクション。コストは高く、ドメイン知識のサポートが必要です。
アンケート	ユーザー数が多く、一度の面談は不可能で、コストも安い。
現場視察	より複雑なプロセスと操作の場合。
ビジネス実務に参加する	問題の性質を効果的に発見し、その解決策を見つけます。
共同要件計画 (JRP)	すべての関係者が参加し、アイデアを理解し、相違点を排除し、良好な対話を行い、コストがかかる、高度に組織化されたグループ会議。
ストーリーボード（プロトタイピング手法）	物語が語られる一連の写真。
サンプル調査・サンプリング	数学的統計に基づいて、コストを削減し、迅速に取得します。 サンプルサイズ = a*(信頼性係数/許容誤差)2 注: a は通常 0.25 です。

• ユーザー インタビュー
  ユーザー インタビューは要件を取得するための最も基本的な手段であり、その形式には構造化されたものと非構造化されたものがあります。構造化とは、事前に一連の質問を準備し、的を絞った方法で質問を行うことを意味し、非構造化とは、大まかなアイデアのみを列挙し、面接の具体的な状況に応じて展開することを意味します。最も効果的な面接は、これら 2 つの方法を組み合わせて実施されますが、結局のところ、すべてを明確に計画することは不可能であり、適切な柔軟性を維持する必要があります。
  ユーザーインタビューは柔軟性が高く、応用範囲も広いです。しかし、ユーザーが多忙で時間調整が難しい、インタビュー時の情報量が多く録音が難しい、コミュニケーションに多くのスキルが必要であり、システムアナリストにも十分な専門知識が必要であるなど、さらに、面接中に、会社の機密事項や機密性の高い話題に遭遇する場合もあります。したがって、この一見単純なテクノロジーには、システム アナリストの豊富な経験と強力なコミュニケーション スキルも必要です。

• アンケート
  調査ユーザーインタビューと比較して、短時間かつ低コストで大量の回答データを収集できる; アンケート調査は匿名で回答できるため、ほとんどのユーザーが生の情報を提供できる; アンケート調査は結果が得られやすい整理して数える。しかし、アンケート調査の最大の欠点は、柔軟性に欠けることであり、その他の欠点としては、
  ① 両者が会っていないこと、システムアナリストがユーザーの表情やその他の行動から暗黙的な情報を得ることができず、ユーザーにはその機会がないこと質問に対する自分の意見をすぐに明確にすること。曖昧な答えや不正確な答え。
  ② ユーザーは心理的に小さなフォームに注意を払わず、真剣に受け止めない可能性があり、その結果、フィードバック情報が不完全になる可能性があります。
  ③ アンケートでは質問に答えることができず、詳細が理解できない場合があります。
  ④ 回答者の数は予想よりも少ないことが多く、ユーザーが質問に答えたり、すべての質問に詳しく説明したりするという保証はありません。

• サンプル調査/サンプリング サンプル調査/サンプリングとは、母集団から代表的なサンプル セットを
  体系的に選択するプロセスを指します。選択されたサンプル セットを注意深く調査することで、母集団全体に関する有益な情報が明らかになります。情報システムの開発では、既存のシステムのドキュメント (ファイル) がサンプリング母集団となります。システムの要件分析を開始するときは、既存のシステムのドキュメントを確認することが、システムを予備的に理解するための最良の方法です。しかし、システム アナリストはどのような種類のドキュメントを参照する必要がありますか? ドキュメント内のデータが大きすぎて 1 つずつ調査できない場合は、サンプリング手法を使用して代表的なデータを選択する必要があります。サンプリング技術はデータ収集だけでなく、ユーザーへのインタビューやユーザーの収集・観察にも活用できます。人々をサンプリングする場合には、上で説明したのと同じサンプリング手法が適用されます。サンプリング技術により、母集団全体ではなく部分を選択することで、データ収集プロセスが高速化されるだけでなく、効率も向上し、それによって開発コストが削減されます。さらに、サンプリング技術は数学的統計の原理を使用して、データ収集の偏りを軽減します。ただし、サンプリング技術は統計原理に基づいているため、サンプルサイズの決定は、期待される信頼性と既存の事前知識に依存し、システムアナリストの主観的な要素、個人的な経験、経験に大きく依存します。依存性が高く、システム アナリストには高度で豊富な経験が求められます。
  

• 共同要件計画 (JRP)
  JRP は要件を取得する比較的高価な方法ですが、非常に効果的な方法でもあります。主要なユーザー代表、システム アナリスト、開発チームの代表者が集まり、組織的な要件について議論します通常、この会議の参加者数は6 ～ 18 名で、所要時間は 1 ～ 5 時間です。
  JRP の主な目的は、要件を分析して検証することではなく、要件を収集することです。JRP を実施する際には、次の主な原則を理解する必要があります。
  ① JRP を実施する前に、詳細な議題を策定し、厳密に従う必要があります。
  ② 定められたスケジュールに従って実施します。
  ③ 会議の内容はできるだけ完全に記録するように努めてください。
  ④ ディスカッション中は専門用語の使用を避けるようにしてください。
  ⑤ 紛争解決スキルを駆使する。
  ⑥ 会議中は十分な休憩時間を設けます。
  ⑦チームの合意形成を促す。
  ⑧ JRP に参加するすべての関係者は、事前に合意されたルールを遵守するようにしてください。

2.5.2 要件分析

要件分析: 優れた要件には、曖昧さのなさ、完全性、一貫性、テスト容易性、確実性、トレーサビリティ、正確性、必要性などの特性が備わっている必要があるため、分析者は乱雑なユーザー要件を組み合わせて、期待をユーザーのニーズに変換することが要件分析の仕事です。

要件分析の作業:
(1)システムコンテキストスコープ図の作成
(2)ユーザーインターフェイスのプロトタイプの作成
(3)要件の実現可能性の分析
( 4)要件の優先順位の決定
(5)要件のモデルの確立
(6)データの作成辞書
(7) QFD (品質機能展開) を使用する

2.5.2.1構造化分析手法 - SA

構造化分析手法SAの中核となるのがデータ辞書です。このコアの周囲には、データ モデル、機能モデル、および動作モデル (状態モデル)という 3 つのレベルのモデルがあります。

構造化分析の手順は次のとおりです。
(1) ビジネスの状況を分析し、現在の物理モデルを反映したデータ フロー図 (Data Flow DiagramDFD) を作成します。
(2) 等価ロジスティックモデルの DFD を導出します。
(3) 新しい論理システムを設計し、データ辞書とプリミティブ記述を生成します。
(3) マンマシンインターフェースを確立し、ターゲットシステムの物理モデルの代替 DFD を提案します。
(5) さまざまなオプションのコストとリスクレベルを決定し、それに応じてさまざまなオプションを分析します。
(6) プランを選択します。
(7) 完全な要件仕様を確立します。

構造化分析手法SAにはデータフローとコントロールフローがあり、よく使われる手法としてはデータフロー図(DFD)やデータディクショナリがあります。

2.5.2.1.1 SA - データディクショナリ DD

データ ディクショナリは要件分析モデルの中核です。これは、データ フロー図内のデータ フローまたはファイルを構成する各データ フロー、ファイル、プロセス、およびデータ項目の説明です。

データ ディクショナリには、データ フロー、データ項目、データ ストレージ、基本処理の 4 つのカテゴリのエントリがあります。データ要素、データ構造、データ フロー、処理ロジック、外部エンティティが含まれます。以下に示すように:

2.5.2.1.2 SA - データ フロー図 DFD

データ フロー ダイアグラム (DFD) は、データ フロー図を使用して機能モデルを表現します。DFD は、システムによって完了する機能を記述します。データの送信と処理の観点から、グラフィック シンボルを使用してシステムの各コンポーネントの機能を記述し、レイヤーごとの細分化によるそれらの間のデータ転送の状況を示し、システムによって完了する機能を示します。以下に示すように:

このうち、DFD には「トップレベル DFD マップ」と「0 レイヤ DFD マップ」もあります。

上図に示すように、「絵素」には次のような記述があります。

次のような間違った DFD 図が添付されています。

上に示すようなエラー:

処理 3.1.2 は入力はありますが出力はありません。これは「ブラック ホール」と呼ばれます。
処理 3.1.3 には出力がありますが、入力はありません。それを「奇跡」と呼びましょう。
処理 3.1.1 では、入力が出力を生成するのに十分ではありません。これを「グレー ホール」と呼びます。

2.5.2.1.3 SA - 状態遷移図 STD

状態遷移図は動作モデルを表すために使用されます。STD は、システムの状態と、システムの状態遷移を引き起こすイベントを記述して、特定のイベントの結果としてどのようなアクションが実行されるかを示すことによってシステムの動作を表します。以下に示すように:

2.5.2.1.4 SA - ER図/エンティティ関係図

ER 図は主にエンティティの属性とエンティティ間の関係を記述します。なお、ERモデルは構造化時代のモデル・産物であり、オブジェクト指向やUMLには存在しません。以下に示すように:

弱い存在とは何でしょうか？
例: 人事管理システムでは、従業員の子供に関する情報は従業員の存在に基づいています。子供エンティティは弱いエンティティであり、子供と従業員の関係は依存関係です。したがって、従業員は存在であり、強い存在にもなり得るのです。
強いエンティティと弱いエンティティの関係は 1:1 または 1:N のみです。

2.5.2.2オブジェクト指向分析手法 - OOA

いくつかの関連する概念

物体	属性[データ] + メソッド[操作] + オブジェクトID/識別ID
クラス [詳細は以下を参照]	エンティティクラス/コントロールクラス/バウンダリクラス エンティティクラス：データ型を問わずデータベースと対応関係があることが多い コントロールクラス：エンティティクラスとバウンダリクラスを繋ぐクラスバウンダリクラス： 外部と通信する クラスシステムの境界3 つの類似した MVC モデル間の関係、それらの考え方は同じ
継承と一般化	再利用メカニズムは、一種の密結合です。親クラスが変更されると、サブクラスも変更する必要があるためです。継承は既存のインスタンスに基づいて行われます
カプセル化	オブジェクトのプロパティと実装の詳細を非表示にし、インターフェイスのみを外部に公開します
ポリモーフィズム	異なるオブジェクトは同じ情報を受け取り、異なる結果を生成します。
インターフェース	メソッド定義のみを持ち、メソッド実装を持たない特別なクラス
過負荷	クラスには、同じ名前で異なるパラメーターの型を持つ複数のメソッドを含めることができます。同じ名前でパラメータが異なる関数の特徴は次のとおりです。
消息和消息通信	メッセージは非同期で通信されます
上書きと書き換え	サブクラスの同じ名前のメソッドは、親クラスの同じ名前のメソッドをオーバーライドします。
組み合わせと集約	集合関係：自動車部品と車両全体の関係（全体と部品のライフサイクルは異なる） 結合関係：部門と会社間の関係。会社が倒産したら部門は終わる（全体のライフサイクルは部品のライフサイクルと同じ）

OOA は、大まかに次の 5 つの基本ステップに従います。

（1）确定对象和类：这里所说的对象是对数据及其处理方式的抽象，它反映了系统保存和处理现实世界中某些事物的信息的能力。类是多个对象的共同属性和方法集合的描述，它包括如何在一个类中建立一个新对象的描述。
（2）确定结构：结构是指问题域的复杂性和连接关系。类成员结构反映了泛化-特化关系，整体-部分结构反映整体和局部之间的关系。
（3）确定主题：主题是指事物的总体概貌和总体分析模型。
（4）确定属性：属性就是数据元素，可用来描述对象或分类结构的实例，可在图中给出，并在对象的存储中指定。
（5）确定方法：方法是在收到消息后必须进行的一些处理方法:方法要在图中定义，并在对象的存储中指定。对于每个对象和结构来说，那些用来增加、修改、删除和选择的方法本身都是隐含的（虽然它们是要在对象的存储中定义的，但并不在图上给出），而有些则是显示的。

2.5.2.2.1 OOA - UML

OOA需求分析的UML（统一建模语言，与平台和语言无关）由基本构造块，规则和公共机制构成。

UML基本构造块之事物【重要组成部分】

事务	描述
结构事物	最静态的部分，包括类，接口，协作用例，活动类，构件和节点
行为事物	代表时间和空间上的动作，包括消息，动作次序，连接
分组事物	看成是个盒子，如包和构件
注释事物	UML模型的解释部分。描述，说明，和标注模型的元素

UML基本构造块之关系【把事物紧密联系在一起】

关系	描述
依赖关系	一个事物发生变化影响另一个事物，包含关系和扩展关系都属于依赖
泛化关系	特殊一般关系，特殊元素的对象可替换一般元素的对象
关联关系	描述了一个链，链是对象之间的连接
实现关系	接口与类之间的关系，一个类指定了由另一个类保证执行的契约

UML基本构造块之图【多个相互关联的事物的集合】

图	描述
静态图	结构图
类图	描述一组类，接口协作和它们之间的关系。
对象图	描述一组对象以及它们之间的关系。对象图往往只在需要描述复杂算法时才会使用，画出来的对象图往往不会只有一个对象。
构件图	也叫组件图，是描述软件内部物理组成的一种图。系统里有哪些构件 构件之间有啥联系。描述一个封装的类和它的接口，端口，以及由内嵌的构件和连接件构成的内部结构。强调由小的部件构件大的系统。
部署图	表示为软件和硬件之间的映射。为了完成系统需要什么样配置的操作系统，内存，CPU等不在它范畴内，它只解决开发的系统如何去部署的问题。
制品图	描述计算机中一个系统的物理结构。制品包括文件，数据库，和类似的物理比特集合。
包图	将某些类放入“包”中，通过包图来组织业务概念图。
组合结构图	展示该部分内容“内部”参与者的配置情况。这个图不常用。
动态图	行为图
用例图	系统与外部参与者的交互。描述一组用例，参与者及他们之间的关系的图。
顺序图	强调按时间顺序。顺序图和通信图我们又称其为交互图。顺序图能够表达用户与系统的复杂交互过程。
通信图	也叫协作图，它强调的是相互之间关系，是顺序图的另外一种表达。
定时图	消息跨越不同对象或角色的实际时间。交互图的一种。
交互概览图	活动图与顺序图的结合。这个图不常用。
活动图	类似程序流程图，表示流程性的东西和并行的行为。它将进程或其他计算结构展示为计算内部一步步的控制流和数据流，它专注于系统的动态视图，它对系统功能建模和业务流程建模特别重要；并强调对象间的控制流程。
状态图	从某个物品的状态是如何变化的角度来展示流程。

UML规则

是构造块如何放在一起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。

UML公共机制

是指达到特定H标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制4种。规格说明是事物语义的细节描述，它是模型真正的核心：UML为每个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息；UML包括两组公共分类：类与对象（类表示概念，而对象表示具体的实体)、接门与实现（接口用来定义契约，而实现就是具体的内容)；扩展机制包括约束（扩展了UML构造块的语义，允许增加新的规则或修改现有的规则）、构造型（扩展UML的词汇，用于定义新的构造块）和标记值（扩展了UML构造块的特性，允许创建新的特殊信息来扩展事物的规格说明）。

UML中的概念

• 类：是描述具有相同属性、方法、关系和语义的对象的集合，一个类实现一个或多个接口。
• 接口：是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作。
• 构件：是物理上或可替换的系统部分，它实现了一个接口集合。提供一组接口的实现，是组成事物的元素。
• 包：是用于把元素组织成组的通用机制，它一个构件的抽象化的概念，是把类元按照一定的规则分成组（或称为模块）。
• 用例：是描述一系列的动作，产生有价值的结果。
• 协作：定义了交互的操作，是一些角色和其它事物一起工作，提供一些合作的动作，这些动作比事物的总和要大。
• 节点：是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。

2.5.2.2.2 OOA - UML 4+1视图

现有的UML，再有的UML视图

UML采用4+1视图来描述软件和软件的开发过程，其中进程视图绘制了所设计的并发与同步结构；部署视图表示软件到硬件的映射和分布结构；UML中的类图可以用来表示4+1视图中逻辑视图；最终形成用例视图，用来得到需求分析模型。

“4+1”视图模型是从不同的视角、使用多个并发的视图来组织软件架构的描述。

“4+1”视图模型具有普遍适用性，实践证明能在许多大型项目中成功运用。

2.5.2.2.3 OOA - 用例模型与分析模型

在OOA的需求分析中，图的应用是经常被用到的。大部分的以用例模型和分析模型的建立为主线，其中用例模型采用用例图来构建，分析模型用类型表示。其它细节情况，也可以建立其它交互图。

2.5.2.2.4 需求分析工具

2.5.2.2.4.1 使用用例建模系统需求

用例建模来源于面向对象建模技术，但该技术也在非对象开发环境中比较流行，用例建模技术对传统的系统分析和设计工具进行了补充，例如数据建模和过程建模， 也提供了架构决策和用户界面设计决策的基础。

用例建模促进并鼓励了用户参与，具有如下优点：

• 提供了捕捉功能需求的工具。
• 有助于将系统分解为更易于管理的小块。
• 提供了与用户以及其他关心系统的关联人员进行交流的工具。
• 辅助估计项目范围、投入和进度。
• 提供了需求跟踪的工具。
• 提供了确定数据对象或实体的起点。
• 提供了设计用户和系统接口的功能规格说明。

为了决定用例的重要性，项目经理或者系统分析员将填写用例分级和评估矩阵，并使用来自关联人员和开发团队的输入构造用例依赖关系图。

1、项目经理使用称为用例分级和评估矩阵，决定用例的优先级。该矩阵使用6个标准按1 ~ 5级评估用例。6个标准是：

• 对架构设计的重要影响。
• 容易实现但包含重要功能。
• 包含有风险、时间紧迫或复杂的功能。
• 需要大量的研究或者新的、有风险的技术。
• 包含主要的业务功能。
• 将增加或者减少费用。

2、有些用例依赖于其他用例，其中一个用例使系统处于一种状态，该状态是另一个用例的前置条件。我们使用用例依赖关系图建模这种依赖关系。用例依赖关系图具有以下优点：

• 系统事件及其状态的图形化表述有利于对系统功能的理解。
• 有助于确定遗漏的用例。
• 通过描述哪个用例更关键并需要最高优先权，有助于推动项目管理。

2.5.2.2.4.1 数据建模与分析

数据建模是一种为数据库定义业务需要的技术，因为数据模型最终要实现成数据库，所以数据建模有时称为数据库建模。下图是一个简单的数据模型，称为实体关系图。

数据建模的系统概念：

• 实体
• 属性（数据类型、域、默认值）（键）
• 关系

如何构造数据模型？

• 获取实体。
• 构造上下文数据模型：包含基本业务实体及它们之间的自然关系。
• 基于键的数据模型：确定每个实体的键。
• 泛化层次体系：父实体、子实体。
• 具有完整属性的数据模型。
• 分析数据模型：规范化（第一范式、第二范式、第三范式）。
• 将数据需求映射到地点：数据–地点–CRUD矩阵。

2.5.2.2.4.1 过程建模

过程建模源自传统的软件工程方法，可能的过程模型包括程序结构图、逻辑流程图或决策表。本节重点介绍系统分析的过程模型，即数据流图。 数据流图是一种描述通过系统的数据流以及系统实施的工作或处理过程的工具。同义词包括泡式图、转换图和过程模型。

过程建模的系统概念：

• 外部代理：常见的同义词包括外部实体。
• 数据存储：是一个数据的“仓库”，同义词包括文件和数据库。
• 过程：即处理，是在输入数据流或条件上执行，或者对输入数据流或条件做出响应的工作，同义词是转换。分解图、层次图。注意避免过程中三种常见的错误：1）有输入没有输出，黑洞；2)有输出但没有输入，奇迹；3)输入不足以产生输出，灰洞（如输入一个雇员地址，输出一张财务报表）。
• 数据流：所有的过程至少都有一个输入流和一个输出流。数据流是过程与系统环境之间的通信。在数据流图中，有时需要描述分支的数据流或合并的数据流。分支的数据流是一个分成多个数据流的数据流，表示一个数据流的所有或者部分路由到不同目的地。合并的数据流是多个数据流合并成一个数据流后的数据流。合并的数据流指示了不同来源的数据流可以合并成一个报文供后续处理。

如何构造过程模型：

• 构造上下文数据流图：0号数据流图。
• 构造系统功能分解图。
• 事件响应或用例清单：构建分解图后，下一步是确定系统必须响应什么业务事件，（外部事件、时序事件、状态事件）。发现并确定事件和响应的更成功的方法之一是用例的技术。用例分析是确定并建模业务事件、谁触发事件以及系统如何响应事件的过程。
• 事件分解图：把事件处理过程增加到分解图中。
• 事件图：以分解图为提纲，可以为每个事件过程绘制一个事件图。
• 构造系统图：从原始的上下文图中的单个过程“爆炸”出来，在单张图中显示了系统的所有事件，显示了子系统的所有事件。 构造基本图：具有较复杂的事件图的事件过程应该扩展成一个更详细的基本数据流图，每个基本过程都是内聚的，也就是说仅完成一件事。
• 完成规格说明：对以上完成的数据流图中的每个数据流、数据存储和基本过程进行描述，并写进资料库中。对于过程内部的逻辑描述，我们可以使用结构化英语（自然英语+编程逻辑），用于说明过程模型中的基本过程的内部逻辑。但许多过程是由复杂的条件组合的（即业务策略），使用结构化英语不容易表达，此时可以使用决策表。

2.5.2.2.4.1 面向对象分析与建模

面向对象分析涉及到定义信息系统的静态和动态行为模型，而非定义数据和过程模型（这是传统开发方法的特点）。对象的标识，对象的数据部分（属性），对象的行为。

2.5.3 需求定义（形成需求规格）

需求定义的过程也就是形成需求规格说明书SRS的过程，通常有两种需求定义的方法，分别是严格定义方法和原型方法。

严格定义法的特点：所有需求都能够被严格定义；开发人员和用户之间能够准确而清晰的交流；采用图形文字能够充分体现最终系统。

原型法：并非所有的需求都能在开发前被准确的说明；项目参加者之间通常存在交流上的困难；需要实际的可供用户参与的系统模型；有合适的系统开发环境；反复是完全需要和值得提倡的，需求一旦确定就应该遵从严格的方法。

2.5.4 需求确认与验证

需求规格说明书SRS的需求验证也称为需求确认，其活动是为了确定以下几个方面的内容：

（1）SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
（2）SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
（3）需求是完整的和高质量的。
（4）需求的表示在所有地方都是一致的。
（5）需求为继续进行系统设计、实现和测试提供了足够的基础。

需求验证包括了需求评审和需求测试。

需求评审包括了：正式评审和非正式评审。需求验证是需要做用户签字确认，但往往实施起来比较困难，因为需求验证时签字就要负责任，它是验收的标准之一（此时的规格说明书SRS就是需求基线）。需求的评审需要用户的参与。

需求测试，不是运行类的测试而是设计测试用例进行测试，比如告诉你输入是什么输出是什么，所以更加接近于想像性测试，它是验证方向对不对该不该做的过程。需求测试仅仅是基于文本需求进行“概念”上的测试。然而，以功能需求为基础（SA方法）或者从用例派生出来（OO方法）的测试用例，可以使项目干系人更清楚地了解系统的行为。虽然没有在系统上执行测试用例，但是涉及测试用例的简单动作可以解释需求的许多问题。这种测试用例通常称为概念测试用例，即不是真正执行的测试用例，它们可以发现SRS中的错误、二义性和遗漏，还可以进行模型分析，以及作为用户验收测试的基础。在正式的系统测试中，还可以将它们细化成测试用例。

2.6 需求管理（支持，保障）

在软件需求工程中，需求管理贯穿于整个过程中，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。

需求管理是可重复级的一个关键过程域，其目标是为软件需求建立一个基线，供软件开发及其管理使用，使软件计划、产品和活动与软件需求保持一致。从软件需求工程的角度来看，需求管理包括在软件开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。

2.6.1 定义需求基线

需求开发的结果应该有项目视图和范围文档、用例文档和SRS，以及相关的分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在用户和开发人员之间就构成了软件需求的一个约定，它是需求开发和需求管理之间的桥梁。

基线是一个软件配置管理的概念，它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。根据IEEE的定义，基线是指已经通过正式评审和批准的规约或产品，它可以作为进一步开发的基础，并且只能通过正式的变更控制系统进行变化。在软件工程范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且已经经过正式技术评审而获得认可。例如，SRS文档通过评审，其中的错误已经被发现并纠正，则就变成了一个基线。根据国家标准《计算机软件配置管理计划规范》（GB/T 12505-1990）的规定，基线可以分为功能基线、指派基线和产品基线三种，通过评审后的SRS（软件需求规格说明书）属于指派基线。

2.6.2 需求的状态

在需求状态的变化中，项目管理人员首先需要关注的是那些被拒绝和被丢弃的需求。因为这些需求有可能是应该被接受和并被实现的需求，如果不是通过有管理的处理过程，就有可能因为疏忽而被遗漏。同时，也应关注被交付的需求，因为可交付物是项目的成果体现，而可交付物的主要内容就是对需求的实现。

2.6.3 需求变更管理

CCB，变更控制委员会，也成配置控制委员会。
要让变更有序进行，首先需要有一个统一的单位来负责，这个单位一般叫变更控制委员会（Change
Control Board），也叫配置控制委员会（Configuration Control
Board）。CCB由项目干系人中有代表性的人员组成，人数没有限制，一个人也可以。CCB有能力在管理上做出承诺，对建议的配置项变更做出评价、审批及监督已批准变更的实施。CCB是决策机构，一般不参与具体的变更执行工作。

2.6.4 需求变更管理过程

（1）问题分析和变更描述。当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
（2）变更分析和成本计算。当接受该变更提议后，需要对需求变更提议进行影响分析和评估。变更成本计算应该包括对该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
（3）变更实现。当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相应的变更。在计划驱动过程模型中，往往需要回溯到需求分析阶段开始，重新作对应的需求分析、设计和实现等步骤;在敏捷开发模型中，往往会将需求变更纳入到下一次迭代的执行过程中。

常见的需求变更策略：

(1) すべての要件変更は、変更管理プロセスに従う必要があります。
(2) 承認されていない変更を伴う設計および実装作業は行わないでください。
(3) 変更は、どの変更を実施するかプロジェクト変更管理委員会によって決定される必要があります。
(4) プロジェクトのリスク保有者が変更内容を理解できること。
(5) 変更要求の元のドキュメントをプロジェクト構成ライブラリから削除または変更してはなりません。
(6) 統合された各要件変更は、水平的なトレーサビリティを維持するために、承認された変更要求まで追跡可能でなければなりません。

2.6.5 需要リスク

危険な行為には次のようなものがあります。 ① 参加するユーザーが不足している。②ユーザーの分類は無視されます。③ユーザーの要望は増え続けています。④ 曖昧なニーズ。⑤不要な機能。⑥流線型すぎるSRS。⑦不正確な推定。

変更の理由： ① 外部環境の変化。②要件や設計が十分に完成していない。③新しい技術の登場。④ 会社の組織再編により業務プロセスが変化する。

2.6.6 要件の追跡

SRS 内の各ソフトウェア構成項目の要件は、関連するシステム (またはサブシステム) の要件まで双方向に追跡可能である必要があります。いわゆる双方向追跡には、順方向追跡と逆方向追跡が含まれます。順方向追跡とは、SRS の各要件がその後の作業結果で対応する点を見つけることができるかどうかを確認することを指します。逆方向追跡は、逆追跡とも呼ばれ、設計を確認することを指しますドキュメント、コード、テスト ケース、その他の作業結果をすべて SRS で見つけることができるかどうか。