アプリケーションサービスの概念設計における問題整理と ATAM

「TOC思考プロセスとソフトウェアやサービスの問題整理・発見 - 討論妄言録」の続き。

ATAM の枠組で

2009/11/03 21:49:21 mnagaku: 東芝レビューって渋いな。数値化し難いシンボリックな問題にはATAMの枠組みを流用するとイケるんじゃないかとか思ってます。 RT @nsiena トレードオフ分析手法 http://bit.ly/v7HEr
16:37:16 nsiena: . @mnagaku: TOC 思考プロセスから、アーキテクチャ設計・評価手法に話が広がってた。ATAM 辺りなら、CMU/SEI の辺りですかね。ソフトウェアテーキテクチャ的な話も興味のある問題。 re: ATAM <http://bit.ly/1Tylzt>
16:38:16 nsiena: #article 以前読んだ: 「ATAM: Method for Architecture Evaluation」<http://www.sei.cmu.edu/library/abstracts/reports/00tr004.cfm> : CMU/SEI の。
16:39:16 nsiena: #article 読んでる: 「第16回パターン勉強会非機能要求とアーキテクチャ」(PDF) <http://bit.ly/eGQtV> : 鷲崎氏の資料。ATAM とか。ちょうど見つけた。
16:39:16 nsiena: 確かに、ATAM は枠組としては参考になる (他の設計方法論とかも)。一般に機能・非機能・品質などの各要求とされる観点を、別の観点に置き換えると。同様の手法がある程度使えてる。やりたいこととは、いくぶん観点がずれる気がしてる。経験に頼りすぎる感じ。

問題意識の整理

16:40:16 nsiena: 念頭にあることを整理しておこう。
16:42:16 nsiena: まず、整理したいのは。どのような観点を用いるかとか、「(ATAM などの) シナリオ」間の相互影響をどのように捉えるかとか、競合の根源をどのように見つけるかとか。どう作るかよりも、どのようなものを作るか。
16:43:16 nsiena: 実現方式の設計というより、企画・事業設計とか要求工学的な問題。そもそもこの辺りの知識が十分でなくて模索している。ほとんど時間を割けていないしね。
16:45:16 nsiena: 言い換えると。特定の範囲のタスク/プロセスを実現するためのソフトウェア/システムのアーキテクチャでなくて。どのようなタスク/プロセスを創造的にデザインするのか、かしらん。 / 「超上流」って言葉は好きじゃないけれど。
16:47:16 nsiena: もう少し具体的には、ソーシャルアプリケーションサービスのデザインが念頭にある。アプリの概念モデルの設計とか、ユーザ活動が循環するようなエコシステムとか、アプリサービス間の相互活用の成否に関わる観点とか。
16:50:16 nsiena: 概念設計において。提供したいユーザ価値、それを実現する機能やシナリオ、提供者・利用者双方を含めたステークホルダ、それぞれにありえる主要なペルソナ、それらによる活動プロセス、などを併せて考えてみている。検討の過程で、いずれも変動していく。
16:51:16 nsiena: それらの変化を収束させて上で変動の(少)ない観点は何か、収束させて行く上での制約・強制力は何か、などが悩ましいところ。案件ごとに経験的になりがち。なんとかしたい。