![[前の年]](../ICON/back_bn.gif){kind=icon}
![[次の年]](../ICON/next_bn.gif){kind=icon}
IEEE Software (IEEE) Vol.14, No.1
|
William Tepfenhart and James Cusick
IEEE Software,Vol. 14, No. 1, pp. 31-35, January/February 1997
本稿では，キット，フレームワークそしてシステムが，パターン， アーキテクチャスタイルやドメイン分析にどのように適合するのかを 理解するための体系(structure)を提案する．本稿では，この体系を 適用して，キット，フレームワークそしてシステムを開発するためには， どのような情報(特にパターンやアーキテクチャスタイル)が要求されて いるか，またそのような情報がどのようにシステム開発のライフサイクルに 適合するかを示す．さらに，そのトポロジーは潜在的なプロダクトや 研究分野を明らかする．
James Coplien
IEEE Software,Vol. 14, No. 1, pp. 36-42, January/February 1997
パターンのコミュニティにおける指導者の一人であり，Advanced C++の 著者でもあるCoplienは，なぜパターンが重要であるのか，そしてパターンが アーキテクチャにもたらす貢献についての見解を述べている．彼は，パターンの 価値はオブジェクトを遥に越えて広がっていること，パターンは開発する システムのアーキテクチャと同様にソフトウエア開発組織についても考えるための 強力な方法であると論じる．
Robert Monroe, Andrew Kompanek, Ralph Melton, and David Garlan
IEEE Software,Vol. 14, No. 1, pp. 43-52, January/February 1997
本稿では，ソフトウエアアーキテクチャとオブジェクト指向設計との 間の関係を示し，それらは異なった問題を扱っており，異なった 抽象化メカニズムを用いているため，(オーバーラップしている としても)互いに完全に包含することはないことを明らかにする． また，著者はアーキテクチャスタイルとデザインパターンは，設計の 専門知識をカプセル化するための補い合ったメカニズムであること， アーキテクチャスタイルは恐らくパターンよりも，オブジェクト指向方法論に 直接的に匹敵すると論じている．
Norm Kerth and Ward Cunningham
IEEE Software,Vol. 14, No. 1, pp. 53-59, January/February 1997
Christopher Alexander は，町や家やオフィスの建築において， 『パターン』という言葉を考え出した建築家である． 本稿で Kerth と Cunningham は， 建築におけるパターンとアーキテクチャの概念が どのようにソフトウェアに適用できるか示す． 彼らはオブジェクトとアーキテクチャの関係を探索し， プロジェクトの規模が大きくなった時， その2者のギャップは Alexander の『パターン言語』という 考え方により埋めることができると提案している．
Sally Shlaer and Stephen Mellor
IEEE Software,Vol. 14, No. 1, pp. 61-72, January/February 1997
本稿では，ソフトウェア・アーキテクチャを， システムの基盤となる仮想機械(virtual machine) であると定義している． 著者らは，オブジェクト指向分析の方法論を用いて アプリケーションとアーキテクチャの双方をモデル化し， また形式的なパターンを用いて，アプリケーションの概念を どのようにアーキテクチャに対応させるか記述する． 結果として，ツールによりドメイン(問題領域)に特化した ソフトウェア・アーキテクチャのコードを 自動生成することができる． しかし，表記法は汎用的である． 著者らは Timepoint アプリケーションを取り上げて， 彼らの手法の適用方法を示している．
Luqi and Joseph A. Goguen
IEEE Software,Vol. 14, No. 1, pp. 73-85, January/February 1997
形式的手法をうまくソフトウェア開発に適用すれば， 我々は真の工学的学問分野に近づくことができるであろう． 本稿で著者らは，これまで形式的手法の利用を妨げてきた問題を 克服するための提案をしている．
|
IEEE Software (IEEE) Vol.14, No.2
|
Sean Furey
IEEE Software, Vol. 14, No. 2, pp. 28-31, March/April 1997
ファンクションポイント分析は，開発者やユーザがソフトウェア アプリケーションの機能のサイズや複雑さを定量化することを， ソフトウェア利用者に役に立つ方法で助ける． ファンクションポイントは完璧なメトリクスであろうか？ 否．それは役に立つメトリクスだろうか？ 私の経験ではそうである． ファンクションポイントは技術的に独立で，一貫性があり， 反復可能であり，さらにデータを正規化し，比較を可能にし， プロジェクトの範囲やクライエントの見積もりを定める助けとなる． 私は，国際ファンクションポイントユーザグループが出した ファンクションポイントを計数するための計数実践マニュアル リリース4.0規則を用いた実践者としての視点から， これらの問題を論じる．もちろん， 他のファンクションポイント標準として， Mark IIやAlbrechtの原案である規則等も存在する．
Barbara Kitchenham
IEEE Software, Vol. 14, No. 2, pp. 28-31, March/April 1997
ファンクションポイントの概念は， 製品サイズをあらかじめ計測するという純粋な要求を扱う 長い道のりに向かっている．私の心配は， 特定のタイプのファンクションポイント， 例えば米国で普及しているAlbrecht版， そして英国で普及しているSymons Mark II等は， 一部の人が想像するほどわかりやすく単純な計測ではない ということである．
ファンクションポイントは，その構造において ファンクションポイントが妥当な計測になることを妨げる 根本的な欠点を持っている. これは予期せぬ振る舞いをする危険があることを意味している． 例えば，あるプログラムが別のものより大きいと誤って主張したりする． たいていの場合，特定の組織の中で注意を払いながら用いられるならば， おそらくほとんど問題はないだろう．しかし， もしも異なる企業間での開発や保守の契約のための根拠として， 企業間にまたがるベンチマーキングのために ファンクションポイントを利用したり， あるいは汎用な見積りモデルを開発することを望むならば， 問題にぶつかるという無視できないリスクが存在する．
Shari Lawrence Pfleeger, Ross Jeffery, Bill Curtis and Barbara Kitchenham
IEEE Software, Vol. 14, No. 2, pp. 33-43, March/April 1997
最もうまくいく計測のプログラム(計画)は，研究者，実践者 および顧客が協力し合って目的を果たしたり問題を解決するような プログラムである．しかし，こうした協力はまれである． 著者らはこうしたグループ間のギャップを調べ， それらを橋渡しする方法を示す．
Raymond J. Offen and Ross Jeffery
IEEE Software, Vol. 14, No. 2, pp. 45-53, March/April 1997
ソフトウェア改善の探求において，企業はソフトウェア計測に どのくらい大きな意味があるかわかってきつつある． また，ソフトウェア計測が企業の基盤事業戦略にとって 不可欠であればあるほど， より成功の見込みが大きくなることを知りつつある．
Tracy Hall and Norman Fenton
IEEE Software, Vol. 14, No. 2, pp. 55-65, March/April 1997
ますます組織は完全なメトリクスプログラム(計画)を好んで， メトリクスに対するアドホックなアプローチを見合わせてきている． 著者らはメトリクスプログラムの成功に対する一致した要求を明らかにし， 2つの組織におけるプログラムがどの程度要求にかなっていたか考察する．
Dik L. Lee, Huei Chuang and Kent Seamons
IEEE Software, Vol. 14, No. 2, pp. 67-75, March/April 1997
テキスト検索問い合わせのためのベクトル空間モデルの いくつかの簡易化を利用して，著者らは処理効率と， 関連する文書の順位付けとして表されるような検索の有効性の 最適なバランスを探求する．
Karama Kanoun, Mohamed Kaaniche and Jean-Claude Laprie
IEEE Software, Vol. 14, No. 2, pp. 77-86, March/April 1997
伝統的なシステム信頼性の努力は ソフトウェア信頼性に焦点を当てることができなかった． これを改善するために，著者らは記述分析(descriptive analysis)， 傾向分析，および信頼性モデルを用いて，テスト活動の管理， ソフトウェア信頼性の評価，および保守の計画を行う方法を提案する．
Les Hatton
IEEE Software, Vol. 14, No. 2, pp. 89-97, March/April 1997
部品が小さいほどこれに比例して障害は少なくなるという ありきたりな知恵は間違っているかもしれない． 著者は中間のサイズの部品が大きい部品あるいは小さい部品よりも 比例して信頼できることを発見した．更に， 達成可能な障害密度には限界があるかもしれないと述べている．
Colin Fidge, Peter Kearney and Mark Utting
IEEE Software, Vol. 14, No. 2, pp. 99-106, March/April 1997
Quartz法は開発プロセスにおける時間と機能的振る舞いの重要度を 同程度に扱う．プログラム開発を統一フレームワークで モデル化することによって， 実時間かつ並行動作するコードの正当性に対して より確信を持つことができると著者らは主張する．
Xiping Song
IEEE Software, Vol. 14, No. 2, pp. 107-117, March/April 1997
設計手法の統合は多くの恩恵をもたらすが， 設計者はそのような努力をより系統的にかつ経済的に行う枠組みを 欠いている．著者は可能な枠組みについて述べ， これを用いてBoochとOMTの2つの設計手法の統合をガイドする．
|
IEEE Software (IEEE) Vol.14, No.3
|
Barry W. Boehm and Tom DeMarco
IEEE Software, Vol. 14, No. 3, pp. 17-19, May/June 1997
成熟した工学分野において，リスク管理は何世紀にも渡って必要と されてきた．1547年ミケランジェロが聖ペテロ大聖堂を建て始めた とき，彼は崩壊する可能性のある足場の下の領域，資材破損の可能 性，および収容限界についてよく知っていた．この主なリスクのそ れぞれに対して，彼はこれを緩和する計画，つまり，いざというと きの準備(fallback)，安全要因，代替案を用意した．
今日，我々は日常的に，周りの職務，財政戦略の計画，建築工学， 医学において，リスク管理を行っている．では，究極的に危険なビ ジネスであるソフトウェア開発に対して，どのようにこれを適用す るのだろう？
Paul R. Garvey, Douglas J. Phair, and John A. Wilson
IEEE Software, Vol. 14, No. 3, pp. 25-34, May/June 1997
システムが複雑になるにつれて，他のプロジェクトで培われたリス ク管理の経験を入手する手段が，プロジェクトマネージャには必要 になる．この要求に対応するために，著者らは RAMP を開発した． これは危険緩和の経験を見分け，分析し，共有するための対話的支 援を提供するリスク管理情報システムである．
Tony Moynihan
IEEE Software, Vol. 14, No. 3, pp. 35-41, May/June 1997
一団の同種のプロジェクトマネージャに対するこの調査によって， リスク管理に関する驚くべき多様性が明らかになった．
Robert N. Charette, Kevin MacG. Adams, and Mary B. White
IEEE Software, Vol. 14, No. 3, pp. 43-50, May/June 1997
保守におけるリスク管理は開発におけるリスク管理と大きく異なる． より頻繁に，そしてより多様な原因からリスクは発生し，プロジェ クトがリスクに基づいて行動できる自由度はより小さい．著者らは， 米海軍の巨大なソフトウェア保守組織において，この違いにどのよ うに対処したか述べる．
Raymond J. Madachy
IEEE Software, Vol. 14, No. 3, pp. 51-59, May/June 1997
著者は，Cocomoのコスト評価として提出されたコスト要因 (cost-driver)評価のパターン分析に利用されたエキスパートシス テムツールについて述べている．これらの結果によって，ユーザは プロジェクトの関連するリスク源を決定し，順位付けすることがで きる．
Kari KAnsAlA
IEEE Software, Vol. 14, No. 3, pp. 61-67, May/June 1997
厳密なデータを取り入れることでリスク見積りをより正確にするこ とができる．著者はアンケートとプロジェクトの履歴を利用してプ ロジェクトのリスクの偶発性を計算する手法とツールを開発した．
Barbara Kitchenham and Stephen Linkman
IEEE Software, Vol. 14, No. 3, pp. 69-74, May/June 1997
著者らは，不確定性を見積るための4つの主要な要因を調べ，ある 組織の全てのプロジェクトを範囲とするリスク管理を目指す汎用な アプローチが，見積り誤りに対する損失を軽減するのに最も効果的 であると主張する．
Ray C. Williams, Julie A. Walker, and Audrey J. Dorofee
IEEE Software, Vol. 14, No. 3, pp. 75-82, May/June 1997
著者らは，ソフトウェア集約的なDoDプログラムでの6年間の経験に 基いた効率的／非効率的なリスク管理手法について議論するための 手引きとして，SEIで設計されたロードマップを用いる．これらの プログラムは，連続的かつチームに対するリスク管理のSEIアプロー チに従っており，それらの仕事の文化に最もうまく適合するプロセ スと手法を選択した．
Edmund H. Conrow and Patricia S. Shishido
IEEE Software, Vol. 14, No. 3, pp. 83-89, May/June 1997
著者らは，いくつかの革新的なリスク管理の実践を行い高い成功を おさめた分散指令制御プロジェクトから，経験に基づくリスク管理 のガイドラインを規定している．
Igor Tartalja and Veljko Milutinovic
IEEE Software, Vol. 14, No. 3, pp. 90-101, May/June 1997
著者らは，共有メモリ型マルチプロセッサにおけるキャッシュコヒー レンスに対するソフトウェア的解決策の分類を提案し，現存する様々 なアプローチをより完全に理解し，可能な代替策を探求するために この分類が適用できることを示す．
|
IEEE Software (IEEE) Vol.14, No.4
|
Andrew Sears and Arnold M. Lund
IEEE Software, Vol. 14, No. 4, July/August 1997
単純な段階モデルからウォーターフォールモデル，そしてより最近 ではスパイラルモデルのような洗練されたモデルにいたる，一連の ソフトウェア開発プロセスのモデルが，ここ数年で普及してきた． プロセスを概念化する過程において，プロトタイピングと，プロト タイピングの結果がソフトウェアの変化に及ぼす影響の特定という 2つのプロセスが追加されるという重要な変化が，時を経て起きて きた．
John Gould と Clayton Lewis は，有用なソフトウェアを達成する のに最も根本的なこのプロセスの変更についてまとめた．初期設計 は，ユーザはそのソフトウェアで何を成し遂げたいのか，ユーザは それをどのように使うだろうか，といったユーザに対する深い理解 を反映しなくてはならない．ユーザの目標と設計のマッピングを改 善するために，ユーザは設計プロセスに含まれるべきである．ソフ トウェアの品質を向上させるためによりしばしばプロトタイプが導 入されるようになってきているからには，現実に近い方法や状況で そのプロトタイプを使うことでユーザはテストされるべきである． そして，そういったテストの結果を，プロトタイピング活動からの 他の教訓とともに，プロセスにフィードバックして，設計を改良す るべきである．
Laura A. Valaer and Robert G. Babb II
IEEE Software, Vol. 14, No. 4, July/August 1997
GUI開発ツールに投資する前に，ユーザはその利点と欠点を知るべ きである．著者らはユーザのニーズに合ったツールを選択するため のチェックリストを提供する．有用性，機能性，柔軟性，可搬性， サポート，及びコストがその全貌である．
Angel R. Puerta
IEEE Software, Vol. 14, No. 4, July/August 1997
Mobi-D は，インターフェイス設計の全ての関連する側面を，強く 結合した宣言的モデルで表現する，高度に対話的な環境である．そ れは，ユーザ中心の開発を支援し，ユーザタスクのような抽象的な 対象からの構造化設計を可能にする．
Dave Roberts, Dick Berry, Scott Isensee, and John Mullaly
IEEE Software, Vol. 14, No. 4, July/August 1997
Object View Interaction Design は，設計チームがオブジェクト に基いた良いユーザインタフェイス設計を行うことを支援する構造 化設計手法である．OVIDでは構造化プロセスと適切なツールを用い るので，より早くより少ない繰り返しで設計は向上する．
Michael G. Morris and Andrew Dillon
IEEE Software, Vol. 14, No. 4, July/August 1997
従来，人とコンピュータのインタラクションの研究者はシステムの 有用性に焦点を当ててきた．著者らは，システムの実用性をも説明 する，MIS-証明された技術の承諾モデル(MIS-proven technology acceptance model)を適用した．彼らはこの要因がユーザの承諾に 対して大きな意味を持つことを発見した．
Catherine Plaisant, Anne Rose, Ben Shneiderman, and Ajit J. Vanniamparampil
IEEE Software, Vol. 14, No. 4, July/August 1997
著者らは，低労力で高利益である様々な戦略を6つの大きなプロジェ クトに用いることで，従来1年あるいはそれ以上要していた，効果 的なユーザインターフェイス再構築が，幾つかのケースでは数週間 で成し遂げられることを立証した．
Jeffrey Voas, Frank Charron, Gary McGraw, Keith Miller, and Michael Friedman
IEEE Software, Vol. 14, No. 4, July/August 1997
著者らは，非常に希な入力に対する欠陥注入と耐障害性の計測を用 いて，従来のテスト手法を補うことができる自動化されたソフトウ エア環境を作成した．4つのケーススタディに適用した結果，彼ら の手法はソフトウエアをより頑強にする見込みがある．
Wilhelm Rossak, Vassilka Kirova, Leon Jololian, Harold Lawson, and Tamar Zemel
IEEE Software, Vol. 14, No. 4, July/August 1997
複雑なシステムでは，特に高いレベルの調整と統合が求められる． この必要性に取組むために，著者らは汎用フレームワークGenIFを 開発した．これは，開発者が領域特有で大規模なシステム開発での ソフトウエアと統合の課題について理解することを支援する．
|
IEEE Software (IEEE) Vol.14, No.5
|
Andrew P. Kosoresow and Steven A. Hofmeyr
IEEE Software, Vol. 14, No. 5, September/October 1997
コンピュータの使用は，正当な行為と同様に，誤用についてのシグ ニチャを明らかにできる行為の足跡を残す．使用する検査方法に よって，ユーザのキーストローク，使われたシステムリソース，或 いはあるプロセス集合の発したシステムコールなどを記録すること ができる．著者らは，システムコールの足跡，特に通常の振る舞い と変則な振る舞いの間での足跡の構造について予備分析を行い，変 則な振る舞いは一時的に局所化されることを発見した．これらの技 法は，ついには効果的な自動分析監視システムにつながり，更には 他の変則な振る舞いを扱えるよう拡張できるかも知れない．
Nicholas Puketza, Mandy Chung, Ronald A. Olsson, and Biswanath Mukherjee
IEEE Software, Vol. 14, No. 5, September/October 1997
侵入検知システムの利用が増えるにつれて，それらのテストと評価 のためのツールや方法論に対する必要性も増える．著者らは，侵入 をシミュレートして侵入検知システムの効果をテストするソフトウェ アプラットフォームを開発した．彼らのプラットフォームを用い て，ユーザは典型的な使用と疑わしい使用の両方をシミュレートす るスクリプトを記述する．またそのプラットフォームは，ユーザが スクリプトの記述を早く簡単に行えるように記録再生機能を有する． そのプラットフォームは著者らのテスト方法論をサポートする．彼 らはその方法論をここで概説する．そのプラットフォームとテスト 方法論はどちらも，いくつかの異なる侵入検知システムのテストと 比較に用いることができるのだ．
Nayeem Islam, Rangachari Anand, Trent Jaeger, and Josyula R. Rao
IEEE Software, Vol. 14, No. 5, September/October 1997
Web によって，ユーザがコンテンツを直接ダウンロードすることが 容易になった．それはユーザのマシンに保存されるソフトウェアの 量を減らすだけでなく，コンテンツ提供者が異なるベンダーのコン テンツを組み合わせることによってアプリケーションをカスタマイ ズすることを可能にする．しかし，この容易性と柔軟性はセキュリ ティの点から見れば代償を要する．立派に見えるコンテンツには悪 意があるかも知れない．もしそれをダウンロードしてシステムがア クセスしたなら，それはホストネットワークだけでなくユーザのマ シンのデータにも損害を与えたり破壊することができる．このよう に，システムリソースへのアクセスは管理されていなくてはならな い．著者らは FlexxGuard という，動的に保護領域を獲得してコン テンツの操作権限を与えるためにその領域を利用する，柔軟なコン テンツインタープリタを開発した．
Joachim Karlsson and Kevin Ryan
IEEE Software, Vol. 14, No. 5, September/October 1997
どの要求仕様が実際に重要なのかを決定することは難しい．しかし この課題は時間や予算の制約からますます求められている． 著者らは要求仕様の優先付けに対するコスト対価値アプローチを開発し， 2つの商品開発プロジェクトに適用した．
Michael Diaz and Joseph Sligo
IEEE Software, Vol. 14, No. 5, September/October 1997
ソフトウエアプロセスを改善する手段として，多くの組識が 成熟度モデル(Capability Maturity Model)を使うかあるいは 検討している．CMMは本当に役立つのか？ 著者らはモトローラ においてCMMを使用した結果を表すメトリクスとデータを示す．
Martin R. Stytz, Terry Adams, Brian Garcia, Steven M. Sheasby, and Brian Zurita
IEEE Software, Vol. 14, No. 5, September/October 1997
著者らは，分散仮想環境アプリケーションの開発において 初期には不明であり相互依存する要求仕様を獲得するために， ラピッドプロトタイピングと探索的プロトタイピングの技法を 結合する．そしてデータ交換を高速化するために コンテナ化すること(containerization)を用いた．
Bo I. Sanden
IEEE Software, Vol. 14, No. 5, September/October 1997
著者は，並行計算に対するより直接的で効率の良いアプローチ として，統制されたマルチタスク(disciplined multitasking) 手法とエンティティ寿命(entity-life)モデリングを提案する． そしてこの手法を自動制御システムにどのように適用できたか を示す．
|
IEEE Software (IEEE) Vol.14, No.6
|
James Bach and W. Michael McCracken
IEEE Software, Vol. 14, No. 6, November/December 1997
James Bach と Michael McCracken は，ソフトウェアエンジニアが ソフトウェア工学の実際を最もよく学ぶことができるのは，産業界 における徒弟制度によってなのか，大学における形式的教育によっ てなのかについて議論する．彼らの論ずる視点は両環境の長所を示 し，両者が相互に作用しうる共同的な方法を提案する．
Steve Tockey
IEEE Software, Vol. 14, No. 6, November/December 1997
ソフトウェア開発が真の工学分野となりうる前に，その実務者は計 算機科学，離散数学，そして今日たいていの大学の課程においては めったに扱われない科目すなわち工学経済についてよく教育を受け なければならない．
Ray Dawson and Ron Newsham
IEEE Software, Vol. 14, No. 6, November/December 1997
たいていのソフトウェア工学の卒業生は，実世界の状況に対する正 しい認識がないままに職に就く．大学はこの環境をシミュレートす る手段を持っているか？ 或いはソフトウェア企業はそういった教 育を自分自身でしなくてはならないのか？
Thomas B. Hilburn
IEEE Software, Vol. 14, No. 6, November/December 1997
我々の専門的職業を促進するために，ソフトウェア工学教育は改善 されるべきである．著者はこれを達成するための，人とプロセスと 技術の3つ組を基礎とする概念モデルを提案する．そして彼のモデ ルに従ったカリキュラム例を概説する．
Kathy Beckman, Neal Coulter, Soheil Khajenoori, and Nancy R. Mead
IEEE Software, Vol. 14, No. 6, November/December 1997
ソフトウェア工学教育に関しては，産業界が必要とするものと大学 が提供するものの間にギャップが存在する．このギャップを埋める ために，著者らは大学のソフトウェア工学課程と産業の間の幅広い 協調を提案する．彼らはこの協調のためのモデルを提案し，3つの 実世界のベンチャーに光を当てる．
Gerald M. Powell, Jorge L. Diaz-Herrera, and Dennis J. Turner
IEEE Software, Vol. 14, No. 6, November/December 1997
著者らは，現実のソフトウェアプロジェクトの中で基礎的なスキル を養成し専門的な教育を施す10年間の協調作業について述べている． そのような努力においては，柔軟性，注意深い計画，よいコミュニ ケーションが必要とされる．
Philip Dart, Lorraine Johnston, Cameron Schmidt, and Liz Sonenberg
IEEE Software, Vol. 14, No. 6, November/December 1997
ソフトウエア工学学位プログラムの認可は，ソフトウエア開発が真 の工学的学問分野であることを断言している．メルボルン大学コン ピュータ科学科の著者らは，オーストラリアで初めて完全に認可さ れたソフトウエア工学学位プログラムを作成した経験を議論する．
Les Hatton
IEEE Software, Vol. 14, No. 6, November/December 1997
n-バージョン開発技法は，一つの「良い」バージョンを作るより信 頼でき，かつ長い目で見ればコスト効率がよいことを示す証拠があ る．多様で独立した開発経路(channels)を並列に利用するのは，特 に障害コストが高いような状況下において，現在の最高水準よりも ずっと優れていると著者は結論する．
Christof Ebert
IEEE Software, Vol. 14, No. 6, November/December 1997
Christof Ebertは，学問分野としてのソフトウエア工学の現況，そ の起源や内在する矛盾，他の工学の学問分野との関係，どこへ向かっ ているのか，その方向性に影響を与えるために我々は何ができるか について彼の考えを示す．松原友夫，Todd Webb, Mauro Pezze, そ してOlav W. Bertelsenはさらに洞察すべき範囲を提示する．