アーキテクチャではトレードオフは避けられない
「間違いだらけのソフトウェア・アーキテクチャ」を立ち読みして面白かったのでメモ。
【参考】
技評刊「間違いだらけのソフトウェア・アーキテクチャ」は面白い - Macテクノロジー研究所
書評「間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価」 データベースコンサルタントのノウハウちょい見せ
アーキテクチャーではトレードオフは避けられない - Strategic Choice
Peace Pipe: ソフトウェアアーキテクチャ その9 - アーキテクチャ設計の実際 [arch]
アーキテクチャをレビューする方法(ATAM) データベースコンサルタントのノウハウちょい見せ
宇宙人、SE、アジャイル教の教祖とか、皮肉っぽい登場人物との会話が面白い。
興味深かったのは、「アーキテクチャのインプットは非機能要求が必ず入る」「非機能要求は品質特性図から考えた方が分かりやすい」という指摘。
その手法として、ATAM(Architecture Tradeoff Analysis Method)やADD(Attribute Driven Design)という考え方がある、とのこと。
実は、「実践ソフトウェアアーキテクチャ」にATAMもADDも既に説明されている。
ATAMは、品質特性図というツリー状の要求分析によってシナリオを作りアーキテクチャを検証する。
ADDは「品質特性駆動型設計」の訳語の通り、品質特性からアーキテクチャを考えて設計していくこと。
これらの考え方はいずれもソフトウェアプロダクトライン、つまり製品系列の開発につながるのが意外だった。
おそらく、コア資産という共通部品や基本アーキテクチャを作るには、性能や汎用性などの可用性、保守性、移植性などの品質特性を考慮しなければ、作っても意味がないことを示唆しているのだろう。
ソフトウェアの品質は掴みどころがない。
品質といえば、信頼性の意味で捉えがちだが、性能要件という可用性(Availability)や保守性、移植性、使用性などたくさんある。
そこからシステムを考えるというやり方は、実はソフトウェア開発者は正直やっていないのではないか?
また読み直してみる。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 相殺フィードバックを再考(2020.06.17)
- SaaSのビジネスモデルがアジャイル開発を促進したという仮説(2020.06.14)
- なぜなぜ分析、FMEA、FTAの違い(2020.06.09)
コメント