アーキテクチャではトレードオフは避けられない
「間違いだらけのソフトウェア・アーキテクチャ」を立ち読みして面白かったのでメモ。
【参考】
技評刊「間違いだらけのソフトウェア・アーキテクチャ」は面白い - Macテクノロジー研究所
書評「間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価」 データベースコンサルタントのノウハウちょい見せ
アーキテクチャーではトレードオフは避けられない - Strategic Choice
Peace Pipe: ソフトウェアアーキテクチャ その9 - アーキテクチャ設計の実際 [arch]
アーキテクチャをレビューする方法(ATAM) データベースコンサルタントのノウハウちょい見せ
宇宙人、SE、アジャイル教の教祖とか、皮肉っぽい登場人物との会話が面白い。
興味深かったのは、「アーキテクチャのインプットは非機能要求が必ず入る」「非機能要求は品質特性図から考えた方が分かりやすい」という指摘。
その手法として、ATAM(Architecture Tradeoff Analysis Method)やADD(Attribute Driven Design)という考え方がある、とのこと。
実は、「実践ソフトウェアアーキテクチャ」にATAMもADDも既に説明されている。
ATAMは、品質特性図というツリー状の要求分析によってシナリオを作りアーキテクチャを検証する。
ADDは「品質特性駆動型設計」の訳語の通り、品質特性からアーキテクチャを考えて設計していくこと。
これらの考え方はいずれもソフトウェアプロダクトライン、つまり製品系列の開発につながるのが意外だった。
おそらく、コア資産という共通部品や基本アーキテクチャを作るには、性能や汎用性などの可用性、保守性、移植性などの品質特性を考慮しなければ、作っても意味がないことを示唆しているのだろう。
ソフトウェアの品質は掴みどころがない。
品質といえば、信頼性の意味で捉えがちだが、性能要件という可用性(Availability)や保守性、移植性、使用性などたくさんある。
そこからシステムを考えるというやり方は、実はソフトウェア開発者は正直やっていないのではないか?
また読み直してみる。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- ChatGPTにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法を聞いた(2023.02.01)
- DDPは品質管理に役立つのか(2022.12.13)
- 組合せテストにおける因子と水準はどちらを最優先で考えるべきか(2022.12.04)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
コメント