アーキテクチャではトレードオフは避けられない
「間違いだらけのソフトウェア・アーキテクチャ」を立ち読みして面白かったのでメモ。
【参考】
技評刊「間違いだらけのソフトウェア・アーキテクチャ」は面白い - Macテクノロジー研究所
書評「間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価」 データベースコンサルタントのノウハウちょい見せ
アーキテクチャーではトレードオフは避けられない - Strategic Choice
Peace Pipe: ソフトウェアアーキテクチャ その9 - アーキテクチャ設計の実際 [arch]
アーキテクチャをレビューする方法(ATAM) データベースコンサルタントのノウハウちょい見せ
宇宙人、SE、アジャイル教の教祖とか、皮肉っぽい登場人物との会話が面白い。
興味深かったのは、「アーキテクチャのインプットは非機能要求が必ず入る」「非機能要求は品質特性図から考えた方が分かりやすい」という指摘。
その手法として、ATAM(Architecture Tradeoff Analysis Method)やADD(Attribute Driven Design)という考え方がある、とのこと。
実は、「実践ソフトウェアアーキテクチャ」にATAMもADDも既に説明されている。
ATAMは、品質特性図というツリー状の要求分析によってシナリオを作りアーキテクチャを検証する。
ADDは「品質特性駆動型設計」の訳語の通り、品質特性からアーキテクチャを考えて設計していくこと。
これらの考え方はいずれもソフトウェアプロダクトライン、つまり製品系列の開発につながるのが意外だった。
おそらく、コア資産という共通部品や基本アーキテクチャを作るには、性能や汎用性などの可用性、保守性、移植性などの品質特性を考慮しなければ、作っても意味がないことを示唆しているのだろう。
ソフトウェアの品質は掴みどころがない。
品質といえば、信頼性の意味で捉えがちだが、性能要件という可用性(Availability)や保守性、移植性、使用性などたくさんある。
そこからシステムを考えるというやり方は、実はソフトウェア開発者は正直やっていないのではないか?
また読み直してみる。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- なぜInfrastructure as Codeが必要なのか?(2021.04.18)
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
コメント