ソフトウェア設計とは
システムのソフトウェア・アーキテクチャは、システムの構成または構造を示し、その動作の仕組みを説明します。システムは、特定の機能または一連の機能を実行するコンポーネントの集合です。ソフトウェア・アーキテクチャはソフトウェアを構築できる堅固な基盤を提供します。
一連のアーキテクチャの決定とトレードオフがシステムの品質、パフォーマンス、保守性、および全体的な成功に影響を与えます。一般的な問題や長期的な結果を考慮しないと、システムがリスクにさらされる可能性があります。
最近のシステムでは、複数の高位アーキテクチャ・パターンと原則が一般的に使用されています。これらは、多くの場合、アーキテクチャ・スタイルと呼ばれます。ソフトウェア・システムのアーキテクチャが単一のアーキテクチャ・スタイルに限定されることは稀で、多くの場合、スタイルの組み合わせによってシステム全体が構成されます。
ソフトウェア設計とは
ソフトウェア設計とは、ソフトウェア要件をソフトウェア実装に概念化するプロセスです。これは、ソフトウェア開発ライフサイクル（SDLC）の初期段階であり、集中の対象が問題からソリューションに移行します。
ソフトウェアを概念化する場合、設計プロセスで、ユーザーの要件を課題とし、最適なソリューションの特定に取り組む計画を作成します。計画では、目的のソリューションを実装するための最適な設計を決定する必要があります。
ソフトウェア設計には、要件仕様から実装への移行を支援するすべてのアクティビティが含まれます。ソフトウェア設計プロセスの主要な成果物を以下に示します。
- ソフトウェア要件仕様このドキュメントでは、想定されるシステムの動作について機能要件と非機能要件の形式で説明します。これらの要件は、明確、実践的、測定可能で、ビジネス要件に照らして追跡可能であることが必要です。要件には、ソフトウェアと人、ハードウェア、およびその他のシステムとの連携方法も定義する必要があります。
- 高位設計 高位設計では、システムのアーキテクチャ設計を抽象度の低いサブシステムやモジュールのビューに分割し、相互のやり取りを示します。この高位設計の観点では、システムとその各コンポーネントのモジュール形式での実装に焦点を当て、各サブシステムのモジュール構造と相互のやり取りを認識します。
- 詳細設計 詳細設計には、高位設計でシステムおよびそのサブシステムとして表現されるものの実装が含まれます。このアクティビティは、モジュールとその実装をより詳細に表現したものであり、各モジュールの論理構造、および他のモジュールとの通信インターフェイスを定義します。
ソフトウェア・アーキテクチャとソフトウェア設計の関係
ソフトウェア・アーキテクチャは、実装の詳細を隠ぺいしながらシステムの構造を明らかにします。アーキテクチャは、システム内の要素とコンポーネントの相互作用の仕組みにも焦点を当てます。ソフトウェア設計は、システムの実装の詳細を深く掘り下げます。設計上の重要事項としては、データ構造とアルゴリズムの選択や、個々のコンポーネントの実装の詳細などがあります。
アーキテクチャと設計の問題は、しばしば重複します。厳格な規則でアーキテクチャと設計を区別するのではなく、それらを組み合わせる方が理にかなっています。決定は、明らかにアーキテクチャ的性質になる場合もあれば、設計に重点を置き、アーキテクチャの実現にどのように役立つかを重視する場合もあります。
重要な点は、アーキテクチャは設計ですが、すべての設計がアーキテクチャであるわけではないということです。事実として、アーキテクトは、ソフトウェア・アーキテクチャ（アーキテクチャ設計）と詳細設計（非アーキテクチャ設計）の線引きをする人です。すべてのケースに適合するルールやガイドラインはありませんが、異なる特徴を形式化する試みがありました。
ソフトウェア・アーキテクチャの最近の傾向では、設計は時間の経過とともに進化するもので、ソフトウェア・アーキテクトはシステムを完全に設計するためにすべてを事前に把握することはできないという前提に立っています。設計は、一般的にシステムの実装段階で進化します。ソフトウェア・アーキテクトは、実世界の要件に照らして設計を継続的に学習し、テストします。
アーキテクチャ分析で解決できる問題
セキュリティの問題を引き起こすソフトウェアの欠陥には、主に次の2種類があります。
- 実装のバグ
- 設計の欠陥
コードの実装バグは、控えめに見てもソフトウェア・セキュリティの問題全体の半分を占めています。残りの半分は、設計レベルで発生するその他の種類のソフトウェアの欠陥に関するものです。設計上の欠陥とバグの割合は、ほぼ50/50です。ソフトウェアの健全性を確保するためには、両方をセキュリティ保護する必要があります。世界最高のコード・レビュー・プログラムを設け、世に知られる最強のツールを使用することはできても、このような方法で欠陥を見つけて修正できる可能性は低いといえます。
欠陥を特定する4つの方法
- 基本的な設計原則を分析する。
- アタックサーフェスを評価する。
- 各種の脅威エージェントを列挙する。
- セキュリティ管理策の弱点とギャップを特定する。
設計工程の早期に、設計の欠陥を見つけて修正する方が、デプロイ後に、実装された「欠陥のある設計」にパッチを適用するよりもはるかに経済的です。アーキテクチャ・リスク分析（ARA）、脅威モデリング、セキュリティ管理策設計分析（SCDA）は、設計上の欠陥の検出・修正に役立ちます。
SCDAはARAよりも簡略化されたアプローチです。SCDAは従来のARAレビューよりもはるかに多くの専門家たちによって実施でき、比較的短時間で済みます。最も重要なことは、この簡略化されたアプローチには、アプリケーション・ポートフォリオ全体をカバーできるほどの効率性が備わっているということです。
開発プロセスでアーキテクチャと設計レビューを統合していない組織は、設計レベルと実装の両方で、ソフトウェア全体が連鎖的な欠陥に見舞われていることを発見して驚くことがよくあります。多くの場合、ペネトレーション・テストで発見された欠陥は、ライフサイクルの早期に他の手法を用いれば、もっと簡単に特定することができたでしょう。アーキテクチャ分析の結果に従ってテストを実行するテスターには、多くの場合、より大きなメリットがあります。
