AbstractClub - 英文技術専門誌の論文・記事の和文要約
AbstractClub - 英文技術専門誌の論文・記事の和文要約 |
|
|
|
IEEE Software (IEEE) Vol.18, No.1
Xavier Ferre, Natalia Juristo, Helmut Windl, and Larry Constantine
IEEE Software, Vol. 18, No. 1, January/February 2001
このチュートリアルは, 一般的なユーザビリティプロセスと, その プロセスが従う設計−評価−再設計のサイクルについて議論する. また, ソフトウェア開発組織において管理者がどのようにプロセス を改善すべきか提案する.
George M. Donahue
IEEE Software, Vol. 18, No. 1, January/February 2001
本稿は, ユーザビリティの費用対効果を示す強い証拠について述べ る. 更に, ユーザビリティの利益を受けることができるのはエンド ユーザだけではなく, ソフトウェアやインターネットアプリケーショ ンを開発する組織もユーザビリティ工学から大きな恩恵を受けるこ とができる.
Karla Radle and Sarah Young
IEEE Software, Vol. 18, No. 1, January/February 2001
製品のユーザビリティを改善することにより, 組織の生産性, 競争 力, 収益性が高まる. しかし, ユーザビリティの実践(つまり人間 工学)を組織に取り入れるのはやりがいのあることだ. 本稿は, 人 間工学を組織にうまく導入した事例について述べる. 異なる組織が 共通の問題に直面したが, それぞれの創造的なソリューションは, 特定の状況におけるニーズを満たすことができた.
Jean Anderson, Francie Fleek, Kathi Garrity, and Fred Drake
IEEE Software, Vol. 18, No. 1, January/February 2001
プロセスの早い段階で利用者に注目することは, 製品品質の改善と 手戻り作業の回避という, 開発における2つの聖杯を手にいれるの に大いに役立つ. どんな製品もけして完全にはなりえない. また改 訂が完全になくなることもありえないが, 利用者満足度という非常 に明白な観点で, 我々はなおいくつかの利益を計測することができ る. 利用者の声をプロセス初期に注入することが, 著者らの主たる 目的である.
Shirley A. Becker and Florence E. Mottay
IEEE Software, Vol. 18, No. 1, January/February 2001
企業が Web のユーザビリティを考慮しなかったがために, オンラ インビジネスに失敗するケースが増えている. 著者らはグローバル な視点からユーザビリティを見つめ, グローバルな市場に手を伸ば すために戦略上何をなしうるか指摘する. 彼らはオンラインビジネ スアプリケーション開発に不可欠な要素としての顧客満足度を促進 する, Webベースのユーザビリティ評価モデルの利用を提案する.
Molly Hammar Cloyd
IEEE Software, Vol. 18, No. 1, January/February 2001
e-コマースとB2Bアプリケーションの成長, CRM(顧客情報管理), そ してクリックストリーム(clickstream)解析によって, 我々の利用 者は誰かを知り, 使い勝手の良いアプリケーションを設計すること に対して, 空前の注目が集まってきた. 著者は, 自身の会社が, 従 来のソフトウェア開発モデルから, Web 時間に合わせて Web アプ リケーションを配信する力を備えた利用者主導のプロセスへと変わっ たことについて述べる.
Marc Hassenzahl, Andreas Beu, and Michael Burmester
IEEE Software, Vol. 18, No. 1, January/February 2001
ユーザビリティの定義は非常に幅広いが, いわゆる使う喜び(joy of use)という定義しにくい関連要素が, 最近新たに加わった. 著 者らは, 使う喜びの主な決定要素のひとつである快楽の質と, 利用 者体験の設計に向けた1ステップとしての, 使う喜びとユーザビリ ティの複雑な相互作用を考慮するための体系的な手法を提案する.
Yuri Chernak
IEEE Software, Vol. 18, No. 1, January/February 2001
製品の成功のためには, リリース前の効果的なソフトウェアテスト が重要である. 開発工程でテストケースの有効性を検証するための 新しいメトリクスと関連する方法論に基づいて, 著者はソフトウェ アテストプロセスを改善するためのアプローチを示す.
Eduardo Miranda
IEEE Software, Vol. 18, No. 1, January/February 2001
いくつかのソフトウェア規模見積もり・工数見積もりのための構造 化手法が知られているにも関わらず, たいていの開発従事者とプロ ジェクトマネージャは, 今なおアドホックないわゆる『名人 (expert)』アプローチに基づいた見積もりを作っている. 一対評価 (paired-comparisons)手法は, より正確で精密な『当て推量』に代 わる選択肢を提供する.
John Mylopoulos, Lawrence Chung, Stephen S.Y. Liao, Huaiqing Wang, and Eric Yu
IEEE Software, Vol. 18, No. 1, January/February 2001
目標指向(goal-oriented)の要求分析技法は, 技術的目標のみなら ず組織的目標にも焦点を当てる. その技法によりこれらの目標を達 成するための一連の選択肢を一度選べば, 続くフェイズの間に, よ り正確で完全なものへと練り上げることができる. UMLを例にとり, 本稿はオブジェクト指向分析手法が, 他の目標指向分析技法により 補完されることを論ずる.
IEEE Software (IEEE) Vol.18, No.2
Erran Carmel and Ritu Agarwal
IEEE Software, Vol. 18, No. 2, March/April 2001
著者らは, 集約的共同作業, 国民的なそして組織的な文化の隔たり, そして時間的隔たりを軽減することを目指した新出のアプローチに ついて議論する.
Audris Mockus and David M. Weiss
IEEE Software, Vol. 18, No. 2, March/April 2001
ビジネスニーズからの要求により, しばしば多くの場所に分散して ソフトウェア開発が行われる. 異なる国や大陸にまたがることも多 い. 著者らは, 強く結び付いていながら複数の場所に及んでいる仕 事の項目(チャンク)を特定することによって, そのような環境にお ける協調問題の程度を評価する定量的手法を紹介する. そして, 協 調の必要性を最小限にするために仕事を複数の場所に分散させる手 法を提案する. その手法は, ソフトウェア変更管理システムに記録 された仕事の項目を分析することにより, お互いに強く結び付いて いないソフトウェアの部分を見分ける. 著者らは, この定量分析を 用いて他の場所に開発を移動する候補となるチャンクを特定するた めのプロセスを定義する.
Alexander Repenning, Andri Ioannidou, Michele Payton, Wenming Ye, and Jeremy Roschelle
IEEE Software, Vol. 18, No. 2, March/April 2001
コンポーネントベースのアプローチは, 分散した複数のチームによ る対話的アプリケーションの迅速な設計・実装に, どのくらい適し ているのだろうか？ ドメインエキスパート, コンポーネントフレー ムワークコーディネータ, 開発者, 発行者(publisher), そして利 用者から構成される, 地理的に広い範囲に分散したテストベッドが, 教育アプリケーションを作成し発行している.
Jesus Favela and Feniosky Pena-Mora
IEEE Software, Vol. 18, No. 2, March/April 2001
著者らは, 大規模システムを開発するチームのメンバーを協調させ るという課題に, 学生を習熟させるためのコースを開発した. その コースでの経験に基づいて, 技術的活動と管理的活動を補助する一 連のツール群を統合する, インターネットベースのグループウェア 環境について述べる.
Richard Heeks, S. Krishna, Brian Nicholson, and Sundeep Sahay
IEEE Software, Vol. 18, No. 2, March/April 2001
顧客もソフトウェア開発者も, より大きな利益を得るために, グロー バルなアウトソーシング関係を価値連鎖の上へ押し上げる必要があ る. だがそれにはコストとリスクが伴う. 著者らは, 価値連鎖移 動の成否をわける戦略について調べている. 長期的研究からのケー ススタディによって, 同調すること, すなわち確認された6つの次 元に沿って顧客と開発者の調和を築くことが, 成功のキーとなる戦 略であることがわかった. 我々の世界に国境がないとしてもなお距 離は重要であるから, 同調することは多くの問題をはらんでいるだ ろう. 暗黙の知識, 非形式的な情報, 文化的価値に関して同調する には, 特に距離が制約となる. 顧客はこのこと−そして時を経て起 こる同調に対する外的衝撃−について認識し, 適切なバッファリン グ戦術を採用しなくてはならない.
Christof Ebert and Philip De Neve
IEEE Software, Vol. 18, No. 2, March/April 2001
Alcatel は, スイッチングとルーティングのビジネスにおいて, グ ローバルなソフトウェア開発を目指している. 開発機能をグローバ ルに分散させる理由はたくさんあるが, コストの低い地域に開発セ ンターを開くだけでは成功は保証されない. 著者らは, ほぼ全ての 大陸にわたる 5000人の技術者が関わる実際のグローバルソフトウェ ア開発からの経験をまとめ, ベストプラクティスへと洗練化する.
Rob Battin, Ron Crocker, Joe Kreidler, and K. Subramanian
IEEE Software, Vol. 18, No. 2, March/April 2001
6ヶ国からなる Motorola の技術者チームが基幹業務プロジェクト のソフトウェアを開発した際, 彼らは, 首尾よく顧客に製品を届け るという, 解決しなくてならないグローバル開発の問題に直面した. 著者らは, これらの問題を解決するという自身の経験について議論 し, 同じような問題に直面する他の開発者に対して勧告する.
Werner Kobitzsch, Dieter Rombach, and Raimund L. Feldmann
IEEE Software, Vol. 18, No. 2, March/April 2001
多くのプログラマと好ましいビジネス環境に引き寄せられて, ソフ トウェア開発のインドへのアウトソーシングに対して, ますます企 業は目を向けるようになってきている. 本稿は, 考えられるさまざ まなアウトソーシング形態について調査した後, インドで衛星事業 を始めるという, ドイツの電話会社の経験について報告する.
Huaiqing Wang and Chen Wang
IEEE Software, Vol. 18, No. 2, March/April 2001
オープンソースの成熟度に関する多くの疑惑と神話のために, 組織 はしばしば, 苦労して詳しい情報に基づいたソフトウェア採用の決 定を行う. 著者らは, 一連の典型的なオープンソースソフトウェア に対して, 一般に受け入れられている一連の要求指向の基準を, 体 系的に適用する. 彼らのアプローチと収集したデータによって, こ の新しい状況を進んでいくための実践的ロードマップが示される.
IEEE Software (IEEE) Vol.18, No.3
Michael Deck
IEEE Software, Vol. 18, No. 3, May/June 2001
開発プロセスを, 組織を横断して完全に均一のものにしようとする なら, ソフトウェアプロセスの改善活動は失敗するだろう. 均一で 基本的な実践は重要であるが, プロジェクトやサブプロジェクトは, 特化されたプロセスに対する必要性を持つことになるだろう. 局所 化されたソフトウェア実践の改良に注目することによって, 組織は 特定の要求を満たすようにプロセスを仕立て上げることができ, 結 果としてより多様なプロセス群をうまく扱うことになる. 本稿は, 1つのプロジェクトにおける, ソフトウェア実践の改良と多様性の 扱いについて述べる.
Marina Blanco, Pedro Gutierrez, and Giuseppe Satriani
IEEE Software, Vol. 18, No. 3, May/June 2001
ヨーロッパソフトウェア協会(European Software Institute)は, ヨーロッパの250を超える組織における結果を含む, ソフトウェア プロセス改善(software process improvement; SPI)の経験に関す る最も重要なリポジトリのひとつを保守している. 本稿は, そのリ ポジトリの内容に関して概観し, 組織が改良の導入を計画する助け となるリポジトリSPI知識を生み出すパターンを示す.
Ramkumar Ramaswamy
IEEE Software, Vol. 18, No. 3, May/June 2001
オブジェクト指向を学習する組織にとって, 特に大部分の学習を実 プロジェクトにおいて行わざるを得ない場合, 師匠(Mentor)が重要 となる. 師匠は, アーキテクトであり, 設計コンサルタントであり, プロセスと言語の問題に対する教師でなくてはならない. この多面 的役割は, 特有の難問を与える. 著者は, 自身が多くのオブジェク ト指向アプリケーション開発プロジェクトにおいて師匠として直面 した問題について述べる.
Stan Rifkin
IEEE Software, Vol. 18, No. 3, May/June 2001
ソフトウェア計測が組織のマーケット戦略に沿っていない場合, こ れを実施するはの難しい. 著者は, Michael Treacy と Fred Wiersema の『マーケットリーダのしつけ(The Discipline of Market Leaders)』をガイドとして用いて, 従来のソフトウェア計 測が, 従来のソフトウェアプロセス改善と同様に, 3つの基本的戦 略のうちの2つ, すなわち顧客理解と製品革新において, どのよう にに間違っているのかを示す. もしあなたが組織の戦略的目標を理 解し, それから計測の実践を適合させるならば, 計測の先導はうま くいくだろう.
Barry Boehm, Paul Grunbacher, and Robert O. Briggs
IEEE Software, Vol. 18, No. 3, May/June 2001
著者らは, WinWin 要求交渉アプローチのために開発した一連のグ ループウェア実装について議論する. WinWin アプローチは, シス テムの成功, すなわち重要な投資家が交渉プロセスに参加し, 互い に満足の行く一連の要求へと収束することを要件としている. 特に, 著者らは, 自身の WinWin システムを開発する間に学んだ教訓につ いてレビューする.
Michiel van Genuchten, Cor van Dijk, Henk Scholten, and Doug Vogel
IEEE Software, Vol. 18, No. 3, May/June 2001
本稿は, Baan Company において, テストを支援するために, 日常 的にグループ支援システム(group support system; GSS)を使った 結果について述べる. 著者らは GSS を使った87のテストと, 従来 の102のテストを比較する. その結果から, GSSに支援された成熟し たテストは, より効果的かつ能率的であることがわかる. ソースコー ド1000行毎の大きな欠陥と, 準備とロギングのための人×時間毎の 大きな欠陥の両項目において, 違いは40%に及んだ. しかし, テス トプロセスが正しく守られず, 準備の割合が高すぎる場合には, GSS の恩恵はなくなる.
Drasko Sotirovski
IEEE Software, Vol. 18, No. 3, May/June 2001
著者は, 反復ソフトウェア開発の基本原則について論じた後, 主題 である, 反復ソフトウェア開発を実践に適用するための少数の役に 立つ経験則(heuristics)へと話を進める.
Csaba Egyhazy, Scott Eyestone, and Janet Martino
IEEE Software, Vol. 18, No. 3, May/June 2001
オブジェクト指向技術の比喩を使い, 複数の業務部隊間における責 任と協調をクラスとして表現する, 著者らのプロセス定義手法は, 直接のプロジェクト計画やリスク軽減を超える実用的価値を示す. その手法は, 詳細な業務分割構造を生み, 事後確認(follow-up)業 務のためのより簡潔な契約言語の開発を促進し, 将来の業務に対す る努力水準(level-of-effort)の見積もりを改善し, 継続的なプロ セス改善を可能にする. そのプロセス定義手法はまた, チームメン バーをオブジェクト指向技術の原則と概念へ手ほどきする.
James A. Whittaker
IEEE Software, Vol. 18, No. 3, May/June 2001
開発者とテスタは, 人間のユーザから入力を受け取り, 妥当性を評 価し, 人間のユーザに対する出力を作り出すという考えに心地よさ を感じる. しかし, 人間のユーザというのは方程式のごく一部なの だ. 他方で, 目に見えないソフトウェアのユーザはまた, あまり理 解されず, 時に完全に忘れ去られるような入力を行い出力を得るの だ. しかし, これらの見えないユーザを無視すると対価を支払うこ とになる. これらのユーザを適切に考慮する最初の一歩は, 彼らの 性質と, いかにソフトウェアアプリケーションを失敗たらしめるか について理解することである.
IEEE Software (IEEE) Vol.18, No.4
Lui Sha
IEEE Software, Vol. 18, No. 4, pp.20-28, July/August 2001
次第に複雑さを増すソフトウェアの信頼性と可用性を改善することは，特に社会の重要な機能を保護する取り組みにおいて，深刻な課題である．多様で冗長なシステムを作ることで堅牢性(robustness)が得られるというのは真実だろうか？ 本稿は，ソフトウェアの複雑性，信頼性と，開発リソースの関係について調査する．また，複雑なソフトウェアシステムの堅牢性を改善する方法として，単純性を用いて複雑性を制御するというアイデアに基づいた，フォワードリカバリーアプローチについて紹介する．
HM
Karama Kanoun
IEEE Software, Vol. 18, No. 4, pp.29-33, July/August 2001
時に開発者は，設計多様性(design diversity)を用いて，ソフトウェア実行中の動的な振る舞いをチェックする．設計多様性とは，異なる設計と実現によって同じサービスを作り上げることを目指して，2つ以上の異なるユニットを作り出すことである．もっと有効に新しい設計に使うことができるはずの資源の無駄遣いだと言う人もいる．著者は，ある産業開発環境において，7年以上にわたり多様設計に費やした業務時間の分析事例について述べる．その結果によると，第2の別形態を開発することによってコストは倍増しなかった．
HM
Les Hatton
IEEE Software, Vol. 18, No. 4, pp.34-39, July/August 2001
ソフトウェア技術者は，自分の障害を取り除く能力がそうしたいという目的に見合っていると信じることを推奨されており，設計時にソフトウェア障害を生む可能性についてほとんど考えない．この考え方を変え，そして診断を改善すれば，障害が繰り返されるソフトウェアの傾向を逆転させることができるだろう．
HM
Michel Raynal, Mukesh Singhal
IEEE Software, Vol. 18, No. 4, pp.40-47, July/August 2001
ノンブロッキング・アトミック・コミットメントは，分散システムの技術者や設計者が実践上の関心を持つ，よく知られた合意問題(agreement problem)である．著者らは，この問題を同期/非同期分散システムに関する事例として紹介し，障害検知についての最近の考え方を概観する．彼らはまた，システムエンジニアがこれらの成果を使って，直面する課題に対するより深い洞察をいかに得ることができるかを示す．
HM
William Yurcik, David Doss
IEEE Software, Vol. 18, No. 4, pp.48-52, July/August 2001
著者らは，ソフトウェアの老化(software aging)に対処する2つの相補的な方法を紹介する．彼らのアプローチは，障害が発生する前に，先を見越してソフトウェアを既知の稼動状態へ再初期化し，また障害発生後に，システムが使用可能であり続けるよう即応的にソフトウェアを再構成する．
HM
Hubert F. Hofmann, Franz Lehner
IEEE Software, Vol. 18, No. 4, pp.58-66, July/August 2001
要求工学(RE)は，あらゆるソフトウェアプロジェクトにおける唯一の最重要部であるかも知れない．著者らは，9のソフトウェア組織の，15の REチームに関する実地調査に基づいて，明らかにプロジェクトの成功に貢献する REの実践について，特にチームの知識，リソース配分，そしてプロセスの観点から解明する．そして，最も成功したチームの示したベストプラクティスをまとめる．
HM
Soren Lauesen, Morten Borup Harning
IEEE Software, Vol. 18, No. 4, pp.67-75, July/August 2001
ユーザインターフェイスを設計するに際して，システム内データの概要を提示するべきか，それとも各業務ステップごとに必要なデータだけを見せるべきか？ いずれにおいても効率的な業務支援や理解容易性を保証することはできないので，著者らは両者のバランスをとって，早期にユーザが確認できるようなアプローチを提案する．
HM
Jean-Marc Jezequel, Daniel Deveaux, Yves Le Traon
IEEE Software, Vol. 18, No. 4, pp.76-83, July/August 2001
今日のソフトウェア開発に関する研究の主な課題は，開発者が厳しい納期と予算の中で品質のよい製品を納品する助けとなるような，オーバーヘッドの少ない手法とツールを提案することである．コストと最終製品の信頼性に対する影響のために，この課題は特にテストにおいて顕著である．著者らは，テストをコンポーネントに埋め込み，自己テストを可能にするための軽量アプローチを提案する．彼らはまた，テストの効率を評価するための変異(mutation)技法に基いた手法を提案する．この手法は，最終的にはコンポーネントの品質評価をもたらす．
HM
Linda Upchurch, Gordon Rugg, Barbara Kitchenham
IEEE Software, Vol. 18, No. 4, pp.84-89, July/August 2001
インターネットの急速な拡大は，Webページを計測，評価する新しい方法を必要とする，一連の新しい問題の原因となった．Webサイトデザインに関する膨大な数のガイドラインが発行されたが，Webページの品質を評価するための標準は承認されていない．カードソートは，計測の専門技術がなくても，回答者から品質属性と計測を得ることができるすぐれた方法である．
HM
IEEE Software (IEEE) Vol.18, No.5
Katrina D. Maxwell
IEEE Software, Vol. 18, No. 5, pp.22-25, September/October 2001
比較可能なベンチマーキングデータを収集することは単純な仕事ではない．本稿において著者は，この8年間，ソフトウェア開発プロジェクトの事例を収集し，評価し，分析し，ベンチマークしてきた中で得られた経験について紹介する．彼女は，発見したことをデータ収集とベンチマーキング活動のための一連のガイドラインとして示す．
HM
Chris Lokan, Terry Wright, Peter R. Hill, Michael Stringer
IEEE Software, Vol. 18, No. 5, pp.26-32, September/October 2001
1999年，インターネットソフトウェアベンチマーキング標準グループ(International Software Benchmarking Standards Group; ISBSG)のデータリポジトリ(Data Repository)に対して，ある組織が多くの一連の強化プロジェクトを提供した．その組織は各プロジェクトに対して，リポジトリ内で最も関連の深いプロジェクトと比較した個別のベンチマークレポートを受け取った．ISBSG はまた，その組織の60のプロジェクト集合全体とリポジトリ全体を比較する，組織的ベンチマーキングを実施した．そのベンチマーキングの目的は，その組織に価値のある情報を提供し，リポジトリの匿名性を考慮してベンチマーキング実施の効果を計測することであった．
HM
James T. Heires
IEEE Software, Vol. 18, No. 5, pp.33-39, September/October 2001
本稿は，ベンダー支援のもとでのアプリケーション開発(IT)部門ベンチマーキングに関する調査について述べる．調査は，その組織の定量的性能ベースラインを定め，業界動向と比較した．
HM
Sam Fogle, Carol Loulis, Bill Neuendorf
IEEE Software, Vol. 18, No. 5, pp.40-47, September/October 2001
最近，ソフトウェア生産性コンソーシアム(Software Productivity Consortium)は，プロセス資産ライブラリ(process asset library; PAL)のベンチマーキング調査を実施した．その報告は，新しいPALの構築，或いは既存のPALの改良を試みている組織に対して，重要な一連の考え方を提供した．最高の『ベストプラクティス』を有する組織ですら，他の参加組織のベストプラクティスから継続的な改善活動で使うことのできる宝石を発見した．本稿は，我々がベンチマーキング手法を選択した理由，調査を実施するのに用いたプロセス，そして将来の調査のための重要な教訓について議論する．
HM
Gareth C. Thomas, Howard R. Smith
IEEE Software, Vol. 18, No. 5, pp.48-52, September/October 2001
Sikorsky Aircraft社は，SEI(Software Engineering Institute; 米カーネギーメロン大学ソフトウェア工学研究所)の CMM(Capability Maturity Model; 能力成熟度モデル)に基づた公式格付けを目指して，ソフトウェアベンチマーキングがプロセス改善および評価の活動計画を行う助けになると決断した．ベンチマーキング専門家の助けを借りて，Sikorsky社はベンチマーキングのためのアンケートを作成し，5つの企業を選択してこれを適用した．その結果は，プロセス改善プロジェクトを成功へと導いた．本稿は，ベンチマーキング旅行の準備，アンケートの構造化，結果の収集，そして教訓の評価における活動について述べる．
HM
Brian Witten, Carl Landwehr, Michael Caloyannides
IEEE Software, Vol. 18, No. 5, pp.57-61, September/October 2001
たいていの商用ソフトウェア生産者は，システムのソースコードへのアクセスを保護しているため，組織外の人間が潜在的にシステムセキュリティを改善できる可能性のある様々な計測を行うことを難しくしている．しかし，攻撃者もまた公開されたソースコードを調べて欠陥を見つけることができるのだから，ソースコードアクセスはセキュリティにとって純益となるのだろうか，それとも純損失となるのだろうか？ 問題は関連する技術課題の範囲を越えている．何故なら，ソースコードの公開は知的財産の開示を意味するため，生産者のビジネスモデルに影響を与えるからである．我々はこの問題をいくつかの観点から考察し，結局のところソースコード公開はシステムセキュリティにとって有利に働くと，ためらいながら結論付ける．
HM
Adam Buchsbaum, Yih-Farn Chen, Huale Huang, Eleftherios Koutsofios, John Mocenigo, Anne Rogers, Michael Jankowsky, Spiros Mancoridis
IEEE Software, Vol. 18, No. 5, pp.62-70, September/October 2001
今日の大企業における事業は，通常何千何万のソフトウェアシステムを含む複雑なソフトウェア基盤に支えられている．しばしば企業は，市場の変化に応じてソフトウェア基盤を再設計する必要がある．本稿は，Enterprise Navigator について説明する．アーキテクトはこのシステムを用いて，Web上でデータベース問い合わせを行うことにより，選択された製品とサービスのシステム間接続を可視化する．更に，アーキテクトが占有的な情報の流れを調べ，クラスタリング解析を行って基礎構造を見つけ，特定のビジネスプロセス，或いは機能の構造的進化を検討するための分析ツール群を提供する．このシステムは，AT&T の System Profile Database 上で広く使われてきた．本稿はまた，Enterprise Navigator を使って，いかにアーキテクトが様々な可視化と分析のタスクを実行するのかを示す事例を紹介する．
HM
Peter W. Fach
IEEE Software, Vol. 18, No. 5, pp.71-76, September/October 2001
使用可能であることがわかっている受け入れ済みソフトウェアソリューションの再利用は，今日の成功したソフトウェア開発のひとつのキーである．本寄稿は，よい設計の再利用に焦点をあて，10年に渡る経験に基づいたアプローチを紹介する．今日のたいていの方法論同様，このアプローチもいわゆるフレームワークやデザインパターン(典型的にはソフトウェア関連研究所の奥深くで使われる技術的な補助)に依存している．しかし，ここに紹介されるアプローチは，それらを開発プロセスに完全に統合するという点にまで踏み込んでいる．このプロセスにおいて，フレームワークとデザインパターンは，開発ライフサイクルを通じてユーザ参加を改善するための優れた手段であることが示された．更には，高い度合いのユーザ参加により再利用に適するユニットを決定し，『よい設計』を再利用するという目的を達成することすら可能になる．最終的にこれらのコンセプトは，アプリケーションシステムを適用させる素晴らしい方法を提供する．
HM
IEEE Software (IEEE) Vol.18, No.6
Mark C. Paulk
IEEE Software, Vol. 18, No. 6, pp.pp. 19-26, November/December 2001
XP (Extream Programming) は、インターネットや Webのソフトウェア開発のような 目まぐるしく変化しやすい業界に適したプログラミング手法として支持されてきた。 著者は、XP をソフトウェアの能力成熟度モデル(CMM)の観点で概観し、 二つのアプローチの概要を示す。そして、CMMの観点で XPを批評する。 その結論は、XPのような軽量な方法論は 多くのすぐれたエンジニアリングのプラクティスを奨励し、 二つの観点は互いに補完し合うということである。
YY
James Grenning
IEEE Software, Vol. 18, No. 6, pp.pp. 27-33, November/December 2001
従来の形式的な開発プロセスを採用するある企業において、 XPの多くのプラクティスを取り入れて始められたプロジェクトについて述べる。 そして、経営陣に対してXPをどのように提案したか、 プロジェクトの種がどのように生まれ成長したか、 チームは最初の6ヶ月間でどんな困難に直面したか、 そして何がうまくいったかについて議論する。
YY
Peter Schuh
IEEE Software, Vol. 18, No. 6, pp.pp. 34-41, November/December 2001
著者は、失敗続きのプロジェクトをXPの実践によって活性化する試みについて、 その成功や不十分な点、そして最後に教訓について議論しながら、改めて語った。 特に、著者は最終的な成功はチーム構成に功績があると考える。 XPがすぐにチームの救いになったわけではないが、 XPによってプロジェクトの納期が過ぎた後もアプリケーションを維持することができたのだ。
YY
Charles Poole, Jan Willem Huisman
IEEE Software, Vol. 18, No. 6, pp.pp. 42-50, November/December 2001
Iona Technologies は、 Orbix Generation 3 の保守・機能強化チームが経験した問題を踏まえ、 XPを採用することで事業レベルのベストプラクティスの導入を試みた。 ここで議論された問題は、 操業開始状態から、既存の配備シナリオに対するバグフィックスとアプリケーションの機能強化 を必要とするたくさんのサポート対象顧客を抱えた状態へと移行する企業にとって、共通の問題である。
YY
Lena Holmberg, Lars Mathiassen
IEEE Software, Vol. 18, No. 6, pp.pp. 51-55, November/December 2001
激しく変化するソフトウェア業界の組織が生き残るためには、 競合より安い価格で高品質な製品とサービスを届けるだけでなく、 市場ニーズおよび科学技術の進歩による選択肢の変化に対して、素早く反応できなければならない。 したがって、組織は絶えず自己の能力を改善しなければならない。 著者らはそのような目標に関するジレンマと機会を効果的に取り扱う 方法について、重要な教訓を学んだ。
YY
Lutz Prechelt
IEEE Software, Vol. 18, No. 6, pp.pp. 56-61, November/December 2001
欠陥記録および欠陥データの分析(DLDA, Defect logging and defect data analysis) は、発生頻度の高いプログラマのエラーを減らすことを目指している。 DLDA は Watts Humphrey の Personal Software Process から 生まれたものだが、その学習コストはより低い。 コントロールされた経験は、技術が正しいことを証明する。
YY
Uttara Nerurkar
IEEE Software, Vol. 18, No. 6, pp.pp. 69-71, November/December 2001
Webのユーザインターフェース設計のための多数の処方箋が流行しているが、 Webサイトのユーザビリティは深刻な問題のままである。 Webのユーザビリティと比較すると、伝統的なGUIアプリケーションのユーザビリティの方が数段勝っている。 重要な違いは用いられている設計手法にある。 著者はGUIの設計手法を学ぶことで、Webの設計手法を改善可能であることを示す。
YY
Tapani Kilpi
IEEE Software, Vol. 18, No. 6, pp.pp. 72-77, November/December 2001
メトリクス計画を実施するための模範的な解決策は、 常に何の調整もなく組織にフィットするわけではない。 プロセスの規模と成熟度は、組織ごとに様々である。 ある成熟したソフトウェアプロセスを有する組織では、 あるメトリクス計画に対して作り出された解決策を 環境依存のニーズとオプションに入念に適合させることで かなりの労力を省くことが可能だ。 Nokia社流のソフトウェアメトリクス計画の現実への適用および 典型的な GQM(Goal-Question-Metric) 手法から派生して、 それがどんなふうに助けとなるかについて説明する。
YY
Ralf Lammel, Chris Verhoef
IEEE Software, Vol. 18, No. 6, pp.pp. 78-88, November/December 2001
ソフトウェア資産のための分析・変更ツールの構築は骨が折れる仕事だ。 なぜなら、まず最初に、ソフトウェアの特定プログラミング言語の基本的なパーサーの実装が必要だからだ。 これらの実装は、大抵は公有ではない。 したがって、現在利用されている500以上の言語のどれであっても、パーサー開発は、 とつてもない先行投資を必要とする。 著者らは、実質的にすべての言語についてうまくいくであろう解決策を提案する。 その解決策とは、文法を盗用することで新たなパーサーを迅速に開発するというものだ。 彼らは、学んだ教訓も共有する。
YY
Girish Keshav Palshikar
IEEE Software, Vol. 18, No. 6, pp.pp. 89-97, November/December 2001
形式手法がソフトウェア産業で受け入れられつつある一方で、 業界は形式仕様を最大限に活用できるようにするための現実的なガイドラインを必要としている。 著者は、産業上の形式仕様を利用する人のためのいくつかの実践的秘訣を提供する。 この15のガイドラインは、プロセスとコンテンツを取り扱う二つの領域に分かれる。 著者はまた、Web上で手に入る文献へのページいっぱいの参照を含めた。
YY
リコー
AbstractClub