アーキテクチャ非機能要件
ソフトウェアに対して求められる、機能面以外の要件のことである。
ユーザに使われること、これから先使われていくことを考えたときに非機能的な要件は大きなウェイトを占めるようになってくる。
機能要件と同様に重視されるべきものである。
非機能要件が発生する観点には以下のものがある。
- 変更容易性
- 相互運用性
- 効率性
- 信頼性
- テスト容易性
- 再利用性
アプリケーションの運用時の大きなトラブルは、パフォーマスンスやシステムダウンなど、非機能的な特性によるものが多い。
開発の中でも非機能要件の重要性を認識し、どれだけ非機能面が必要とされるかを確認を行い、テストまでしっかり行うべきである。
変更容易性
ソフトウェアがどれだけ改善しやすいか、ということである。
改善には、修正、拡張、再編成、別プラットフォームへの移行などが含まれる。
この改善を素早く、品質を落とすことなく行われることがソフトウェアに求められる。
変更容易性を確保するため、以下の要素について設計段階から抑えておきたい。
- 保守性
- 拡張性
- 再構築
- 移植性
変更容易性を意識しすぎるあまり、シンプルであることと競合を起こすことがあるため、どこが変更容易であるべきなのかを考えて設計を行うのがよい。
相互運用性
ソフトウェアが、他のソフトウェアとどれだけやり取りしやすいかということである。
外部APIを利用したアプリケーションのように、相互運用性が確保されていることによってソフトウェア間での連携が容易に行える。
他のソフトウェアの利用により用途の選択肢は広がり、接続性がよいほど連携の実装を行いやすくなる。
連携してもらいやすいアプリケーションを作成するためには、標準規格に則って開発を行うのがよい。
効率性
ソフトウェアがリソースを使用する際に、どれほど適切な性能を引き出せているかということである。
時間的な観点からみた時間効率性、コンピュータの持つ性能からみた資源効率性を考える。
コンピュータのリソースを節約するだけではなく、積極的に活用していくことで効率性が高いソフトウェアへ近づく。
設計の段階から性能を最大限引き出すことを意識したい。
信頼性
例外的な場面、予期しない方法での利用をされた際に昨日を維持する能力である。
信頼性には、以下の2つの側面がある。
- フォールトトレランス
障害に対して寛容であること、つまり障害が発生した際に正常な振る舞いを続けることである。
振る舞いは正常でありつつ、内部的には修正を行う。
内部的に冗長性をもたせたり、障害時に機能を絞って処理継続を優先するフェールソフトを考慮する。
- ロバストネス
堅牢であること、つまり不正な使用方法からソフトウェアを保護する能力である。
不正な利用法を想定し、システムとして定義してある状態へ移行するようにする。
障害時に問題が発生した箇所を切り離すフェールセーフ、あらかじめ障害を発生させうる操作を想定した設計を行うフールプルーフを考慮する。
状況次第でソフトウェアに求められる信頼性は異なるため、需要にあった設計を行う必要がある。
テスト容易性
ソフトウェアに対して効果的に、効率的にテストを行う能力のことである。
効果的なテストとは、ソフトウェアの機能を漏らすこと無くしっかりと確認を行えるテストである。
効率的なテストは、テストの作成にかかるコストが少ないテストである。
ソフトウェアの品質の担保にはテストが欠かせない。
そのテストを容易に作成できることはソフトウェアの設計の段階から求められている。
再利用性
ソフトウェアの一部、もしくは全部を別のソフトウェアの開発に再利用しやすいかということである。
ソフトウェアを再利用するという立場と、再利用されるためのソフトウェアを開発するという2つの立場から考える。
開発に再利用を取り入れるためには、あらかじめ再利用を前提とした設計を行い、プラグインを取り入れるためのモジュールを作る。
再利用されるようなソフトウェアを開発する場合、自己充足的になるような設計を行い、全体でもモジュール単位でも独立してビルドできるようなパッケージにする。
できるだけ他のソフトウェアから技術を借りてくることで、時間短縮や品質の担保につながる。