前の記事システム分析とシステムアーキテクチャ設計、ボードをはんだ付けする手、コレクションEK-TMC123GXL開発ボード（溶接技術を無視してください）
SWE.1 |ソフトウェア要件分析
客観的ニーズ分析ソフトウェアは、システムのソフトウェア関連の部分は、ソフトウェア要件のセットに変換する必要があります。
ソフトウェア要件の分析を含みます、
- ソフトウェア要件を指定します。ソフトウェアの必要な機能と性能を決定するために、システム要件とシステムアーキテクチャだけでなく、システム要件とアーキテクチャの変更を使用してください。ソフトウェア要件の機能と非機能のソフトウェア要件を指定します。
-
ソフトウェア要件を整理します。など、ソフトウェアの要求仕様のソフトウェア要件に建設
- プロジェクト関連のクラスタグループ、
- 論理的な順序は、アイテムを命じ、
- プロジェクトの関連規格に従って分類、
- 利害関係者のニーズに応じて優先順位付け。
- 解析ソフトウェア要件。精度、技術的な実現可能性と検証可能性、およびサポートリスクの識別を確実にするために、それらの間の相互依存性を含む特定のソフトウェア要件を分析します。コスト、スケジュール、および技術的な分析への影響。利害関係者のニーズに応じて優先順位付け。
- 動作環境分析への影響。システム要素とインターフェース動作環境のソフトウェア要件への影響。
- 認定基準を策定します。検証の要件については、定性的および定量的尺度を提供する、各ソフトウェアのニーズのための認定基準を策定します。
- 双方向トレーサビリティを確立します。システム要件およびソフトウェア要件間の双方向トレーサビリティを確立します。システム・アーキテクチャとソフトウェアの要件間の双方向トレーサビリティを確立します。
- 一貫性を確認してください。システム要件およびソフトウェア要件との整合性を確認してください。システムアーキテクチャとソフトウェアの要件との整合性を確認してください。
- 合意された通信ソフトウェア要件。更新は、すべての利害関係者に伝達ソフトウェア要件およびソフトウェア要件を合意しました。
でエンタープライズアーキテクトソフトウェア要件を定義します
SWE.2 |ソフトウェアアーキテクチャの設計
目的ソフトウェアアーキテクチャ設計プロセスは、ソフトウェアに割り当てられたどの要素を決定するために、システムアーキテクチャ設計、およびソフトウェア要件を確立すること、およびソフトウェア・アーキテクチャの設計を評価するために定義された基準に従いました。
これは、次のものが含まれます。
- ソフトウェアアーキテクチャ設計の開発。機能性と非機能ソフトウェア要件、開発およびロギングソフトウェアアーキテクチャ設計、ソフトウェアの構成要素を識別します。
- 配布ソフトウェア要件。ソフトウェアアーキテクチャの設計要素へのソフトウェア要件を割り当てます。
- インタフェース定義ソフトウェア要素。インターフェイスは、特定の開発および文書の各ソフトウェア要素。
- 動的挙動を説明してください。評価し、システムの動的挙動を満たすために必要な書類のソフトウェア要素に時間と動的相互作用。
- 資源消費の目標の定義。適切なレベルで識別し、資源消費の対象のすべての関連要素のための文書のソフトウェアアーキテクチャ設計。
- オプションのソフトウェアアーキテクチャの評価。評価基準は、アーキテクチャを定義します。標準規格に基づいたソフトウェアアーキテクチャを改善するための選択肢を評価します。選択したソフトウェアアーキテクチャを記録する基本原理。
- 双方向トレーサビリティを確立します。ソフトウェア要件とソフトウェアアーキテクチャの設計要素間の双方向トレーサビリティを確立します。
- 一貫性を確認してください。ソフトウェア要件とソフトウェアアーキテクチャの設計との整合性を確認してください。
- 合意された通信ソフトウェアアーキテクチャの設計。合意されたソフトウェアアーキテクチャの設計と、すべての利害関係者に伝え、対応する更新情報。
ソフトウェアアーキテクチャ図
ユーザー事例
