アーキテクチャではトレードオフは避けられない

「間違いだらけのソフトウェア・アーキテクチャ」を立ち読みして面白かったのでメモ。

【参考】
技評刊「間違いだらけのソフトウェア・アーキテクチャ」は面白い - Macテクノロジー研究所

書評「間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価」　データベースコンサルタントのノウハウちょい見せ

アーキテクチャーではトレードオフは避けられない - Strategic Choice

Peace Pipe: ソフトウェアアーキテクチャ その9 - アーキテクチャ設計の実際 [arch]

アーキテクチャをレビューする方法(ATAM)　データベースコンサルタントのノウハウちょい見せ

宇宙人、SE、アジャイル教の教祖とか、皮肉っぽい登場人物との会話が面白い。
興味深かったのは、「アーキテクチャのインプットは非機能要求が必ず入る」「非機能要求は品質特性図から考えた方が分かりやすい」という指摘。
その手法として、ATAM(Architecture Tradeoff Analysis Method)やADD(Attribute Driven Design)という考え方がある、とのこと。

実は、「実践ソフトウェアアーキテクチャ」にATAMもADDも既に説明されている。
ATAMは、品質特性図というツリー状の要求分析によってシナリオを作りアーキテクチャを検証する。
ADDは「品質特性駆動型設計」の訳語の通り、品質特性からアーキテクチャを考えて設計していくこと。
これらの考え方はいずれもソフトウェアプロダクトライン、つまり製品系列の開発につながるのが意外だった。
おそらく、コア資産という共通部品や基本アーキテクチャを作るには、性能や汎用性などの可用性、保守性、移植性などの品質特性を考慮しなければ、作っても意味がないことを示唆しているのだろう。

ソフトウェアの品質は掴みどころがない。
品質といえば、信頼性の意味で捉えがちだが、性能要件という可用性(Availability)や保守性、移植性、使用性などたくさんある。
そこからシステムを考えるというやり方は、実はソフトウェア開発者は正直やっていないのではないか？

ソフトウェア品質特性

また読み直してみる。