AbstractClub - 英文技術専門誌の論文・記事の和文要約


[インデックス] [前の年] [次の年]

IEEE Software (IEEE) Vol.22, No.1


必要な時に学ぶか,万一に備えて学ぶか?
Do You Learn Just in Time or Just in Case?

Warren Harrison (Portland State University)

IEEE Software, Vol. 22, No. 1, pp. 5-7 , January/February 2005

Keywords: training, continuing education, just in time, in-service training

企業が従業員に特定のレビュー技法やプログラミング言語を学ぶことを求める場合,『必要な時に(just in time)』教育を行うことを確認するだろう.つまり,従業員はまさに必要なことを,まさに必要な時に学ぶ.しかし,『万一に備えた(just in case)』教育により,従業員をその分野の最新情報に精通させることに興味を示す企業はほとんどない.著者は,『職場トップ100』(Computerworld の調査に基づく)が,どのくらいの時間を教育に割いているか議論する.そして,比較的新しい教育のアプローチと,継続教育に基づく実務訓練を提案する.

HM


手近なツール
The Tools at Hand

Dimidis Spinellis (Athens University of Economics and Business)

IEEE Software, Vol. 22, No. 1, pp. 10-13 , January/February 2005

Keywords: tool, tools of the trade

IEEE Software の新コラムは,ソフトウェア開発と課題に対して適用するツールの相互作用を探索することを狙っている.各回のコラムは,特定のソフトウェア構築活動を,利用できるツール(商用ツール)の観点から議論する.このコラムは,我々のツールがどれほど山積みになっているのか幅広く考察し,著者が選ぶソフトウェアツールの罪トップ10を列挙する.

HM


統合要求工学:チュートリアル
Integrated Requirements Engineering: A Tutorial

Ian Sommerville (Lancaster University)

IEEE Software, Vol. 22, No. 1, pp. 16-23 , January/February 2005

いかなるシステムにおいても,開発に先立って,そのシステムが何をすることを想定しているのか,そのシステムを利用することで,いかにそのビジネスの,或いはお金を払う人々の目的を達成する助けとなるかについて,理解しなくてはならない.これには,アプリケーションドメイン(遠隔通信,鉄道,小口金融,ゲームなど),システム運用上の制約,ステークホルダの具体的な機能要求,そして性能,セキュリティ,信頼性などシステムの重要な性質の理解が必要である.要求工学とは,こうした理解を促進する助けとなり,ステークホルダと開発に携わる技術者に対してシステム仕様を文書化するための,一連の構造化された活動に対してつけられた名前である. 本稿は,要求工学の基本的な活動を紹介し,ソフトウェア開発プロセスの部分としてどのように発展してきたかを議論する,短編チュートリアルである.しかし,確立された要求工学の技法に焦点を当てるよりも,むしろ変化し続けるソフトウェア工学が要求工学への新しい試みに至った経緯を議論する.そして,要求工学を他のシステム実装作業とより密接に統合してこれらの試みの達成を後押しするような,新しい技法を多数紹介する.

HM


パターンを用いて要求工学の経験を共有する
Sharing Requirements Engineering Experience Using Patterns

Lars Hagge, Kathrin Lappe (Deutsches Elektronen-Synchrotron)

IEEE Software, Vol. 22, No. 1, pp. 24-31 , January/February 2005

Keywords: requirements engineering, patterns, pattern analysis, pattern repository

パターン形式で要求工学(RE)の知識獲得を試みることで,実践経験レベルでの知識移行が可能になる.著者らは,プロジェクトにうまく適用されてきた,基本的なRE活動のための4つのパターンを紹介する.彼らはまた,パターンをREの経験を共有するための汎用的な手段として提案し,観察からパターンを導き出す分析手法について述べる.実践者は,この手法をオンラインパターンリポジトリを構築するための基礎として用いて,業務に携わるプロジェクトリーダ達にパターンを活用してもらうことができる.

HM


大規模要求管理のための言語工学的アプローチ
A Linguistic-Engineering Approach to Large-Scale Requirements Management

Johan Natt och Dag (Lund University, Sweden), Vincenzo Gervasi (University of Pisa, Italy), Sjaak Brinkkemper (Utrecht University, the Netherlands), Bjorn Regnell (Lund University, Sweden)

IEEE Software, Vol. 22, No. 1, pp. 32-39 , January/February 2005

Keywords: requirements engineering, large-scale requirements management, natural language processing, linguistic engineering, requirement relationships, requirements similarity, requirement duplicates, redundancy

大市場向けの大きく複雑なソフトウェア製品の開発には,(市場から収集される)顧客要望と(開発組織内で作成される)製品要求の継続的で大量の流入を伴う.根拠の十分な設計上の意思決定を可能にするために,この2つの要求元の相互関係を明確にし,保守していくべきである.残念ながら,今日日常的に行われている手動による関連付けは,めんどうで,時間の無駄で,間違いやすい.著者らは,顧客要望と製品要求の関連付けをサポートする,言語工学に基づく実利的なアプローチを紹介する.本稿は,産業の実要求を用いた評価を含んでおり,そのような自動化サポートが迅速な関連付けを可能にすることを示す.これらのデータに基づいて,著者らはかなりの時間の節約が可能であると見込む.この結果は,明らかになった強化点とともに,ソフトウェア品質の向上と産業の要求工学にかける時間の節約を約束している.

HM


マルチプロジェクト環境における要求工学コミュニケーションを改善する
Improving Requirements Engineering Communication in Multiproject Environments

Barbara Paech (University of Heidelberg), Jorg Dorr (Fraunhofer Institute for Experimental Software Engineering), Mathias Koehler (Nokia)

IEEE Software, Vol. 22, No. 1, pp. 40-47 , January/February 2005

Keywords: requirements engineering, requirements process, software engineering process definition

複雑なマルチプロジェクトの環境では,コミュニケーションが要求工学を成功させる鍵となる.情報モデルを用いると,要求工学を通してステークホルダの文書と責任を得ることができるので,この問題の助けとなる.責任が文書の,そして文書内の,原作者,レビュア,承認,変更伝達を決定する.情報モデルは,依存するプロジェクトのステークホルダが,互いに最も重要なコミュニケーションの必要性に気づくことを,効果的にそして実際的に保証する.著者は,例として Nokia Smart Traffic Products で開発された情報モデルを紹介し,そのモデルを2日間のワークショップでどのように定義したか示す.

HM


ポイント/カウンターポイント
Point/Counterpoint

James Robertson (Atlantic Systems Guild), Connie Heitmeyer (Naval Research Laboratory)

IEEE Software, Vol. 22, No. 1, pp. 48-51 , January/February 2005

要求アナリストは同時に発明者でなければならない/アトランティック・システム・ギルド(Atlantic Systems Guild) James Robertson

アナリストでなくシステム設計者が設計すべきだ/アメリカ海軍調査研究所(Naval Research Laboratory) Connie Heitmeyer

Robertsonは「顧客のために構築するソフトウェアに関して言えば、我々はその一部を発明しなければならない。」と述べている。

Heitmeyerは「要求アナリストの仕事は大部分が発見する類のものだ。既存の文書を調査したり、顧客やドメインエキスパートの要求を顕在化させたり、欠陥のために文書化された要求を分析することによって,アナリストは新システムへの要求を発見する。」と述べている。

HT


システムコーチングについて
On Systems Coaching

Susanne Kandrup (SusKan Development)

IEEE Software, Vol. 22, No. 1, pp. 52-54 , January/February 2005

Keywords: requirements specification, systems coaching, family therapy

良いシステムを作ることは、ユーザの真の要求を発見するための「正しい質問」をすることに依存する。 新たな知識を創造できるインタビューテクニックや異なった種類の質問は家族療法の手法が参考になる。

HT


仕様書に書かれた「すべての」や複数形の構文的な危険性
The Syntactically Dangerous All and Plural in Specifications

Daniel M. Berry (University of Waterloo), Erik Kamsties (University of Duisburg-Essen)

IEEE Software, Vol. 22, No. 1, pp. 55-57 , January/February 2005

Keywords: natural language, syntax, semantics, requirements specification

「すべての」という言葉や複数形は誤用されることで、コンピュータベースシステムの仕様書に曖昧さや他の問題を発生させる。 著者らはこれらの誤用や関連する誤用、それらが原因となって発生する曖昧さや問題点、どのようにそれらを回避するかを述べる。

HT


実務者のための根拠に基づくソフトウェア工学
Evidence-Based Software Engineering for Practitioners

Tore Dyba (Simula Research Laboratory and SINTEF ICT), Barbara A. Kitchenham (NICTA and Keele University), Magne Jorgensen (Simula Research Laboratory)

IEEE Software, Vol. 22, No. 1, pp. 58-65 , January/February 2005

Keywords: evidence, empirical software engineering, evaluation

もしソフトウェアエンジニアがある技術の有効性についての科学的根拠を考慮しなかった場合、彼らは新しい技術の導入について間違った判断を下してしまうかもしれない。 根拠に基づく医療(evidence-based medicine)で用いられた手法がソフトウェア工学にも同様に適用できる。 そのような根拠に基づくソフトウェア工学(evidence-based software engineering : EBSE)はソフトウェアプロセス改善についての最新の考え方にうまく合致し、研究と実践の間にあるギャップを狭める重要な手段になりうる。 しかしながら、EBSEは実施者にとって難易度が高い。というのも現状のソフトウェア工学での研究は限られており、根拠の蓄積や評価を支援するような様式では報告されていないからである。

HT


スープかアートか?経験的ソフトウェア工学において根拠の力が果たす役割
Soup or Art? The Role of Evidential Force in Empirical Software Engineering

Shari Lawrence Pfleeger (RAND)

IEEE Software, Vol. 22, No. 1, pp. 66-73 , January/February 2005

Keywords: risk, decision making, evidence, best practice, reading

ソフトウェアプロジェクトの管理者は、良い事例やベストプラクティスを識別する目的で,リソース、ツール、技術などの様々なことについて意思決定する。 しかしこれらの決断は一般的な見識やベンダーの誇大広告ではなく、具体的な根拠に基づいて行われるべきである。 著者は、様々なタイプの根拠を調査し、それらからどのように論拠を構築するか、より効果的な意思決定を支援するためにはどのように論拠を強化するかを示す。

HT


ソースコードレビューシステム
Source Code Review Systems

Jason Remillard(Soluris)

IEEE Software, Vol. 22, No. 1, pp. 74-77 , January/February 2005

Keywords: inspection, inspection tool, inspections process, open source tool

Soluris のソフトウェア工学グループがインスペクションプロセスの再開を決めた時,紙を使う代わりにインスペクションプロセスを自動化するためのツールを選定する必要があった.本稿では,2つのオープンソースツール Bugzilla, Codestriker と,3つの商用ツール VisualStudio .Net の CodeReview アドオン, CodeReviewer, ReviewPro を比較する.

HM


Webメタデータの標準:調査と処方箋
Web Metadata Standards: Observations and Prescriptions

David Bodoff (Hong Kong Univ. of Science & Technology), Mordechai Ben-Menachem (Ben-Gurion University of the Negev), Patrick C.K. Hung (Hong Kong Univ. of Science & Technology)

IEEE Software, Vol. 22, No. 1, pp. 78-85 , January/February 2005

Keywords: metadata, standards, intelligent Web services, Semantic Web

Webメタデータの標準の急増が、ソフトウェア工学、ソフトウェアの再利用、図書館学、知識表現などの関連する分野から重要な教訓を思い起こす機会を与えてくれる。 これらの標準を推進するのを急ぐことは、そのような教訓が見落とされる危険性を伴う。 加えて、メタデータの標準と人工知能の見かけ上の融合は相互に利益を生み出すように思われるが、同時に相互接続性や、ソフトウェアのテストの考慮、検索ツール、適当なアクセスポイントの提供といったその他の重要な問題から研究者の労力をそらしてしまうかもしれない。 この記事では様々なWebメタデータの標準を吟味し、関連する分野から得られる重要な教訓に注意するように呼びかける。

HT


社内ソフトウェアの開発:成功へと導くプロジェクト管理の慣例はなにか?
In-House Software Development: What Project Management Practices Lead to Success?

June M. Verner (National ICT Australia), William M. Evanco (Drexel University)

IEEE Software, Vol. 22, No. 1, pp. 86-93 , January/February 2005

Keywords: project success, software project management, software development risk, postmortem review

ある調査が、ほぼ完全に社内のソフトウェア開発に携わっている、大企業に属す多くのソフトウェア開発者が行ったソフトウェア開発の慣例を調べた。 その結果、成功するプロジェクトには、プロジェクトマネージャーがプロジェクトの明確なビジョンを持つ必要があり、要求が高品質でなければならず、妥当な要求が識別された後にのみ見積もりが行われるべきであることがわかる。 失敗するプロジェクトにおいては、多くの既知のソフトウェアの慣例が適用されていない。 調査したほとんどのプロジェクトは要求が明確でないまま始められた。 リスク管理は日常的に開発の一部として行われてはおらず、事後分析のレビューを日常的に行っていないため組織は彼らの過ちから学んでいない。 また、上層部の経営者にプロジェクトをうまく遂行するために必要な方法に対しての理解が不足しているように見える。

HT


書評
Bookshelf

Diomidis Spinellis, John R. Dance, David Arthur Eatough, Kevin C. Desouza, Yukika Awazu

IEEE Software, Vol. 22, No. 1, pp. 94-97 , January/February 2005

William H. Press, Saul A. Teukolsky, William T. Vetterling, Brian P. Flannery 著."Numerical Recipes in C++: The Art of Scientific Computing, 2nd edition" (C++の数値レシピ:科学的コンピューティング技術 第2版)

Damien Watkins, Mark Hammond, Brad Abrams 著."Programming in the .NET Environment" (.NET 環境プログラミング)

David Astels, Granville Miller, Miroslav Novak 著."A Practical Guide to Extreme Programming" (エキストリームプログラミング実践ガイド)

Paul Coombs 著."IT Project Estimation: A Practical Guide to the Costing of Software" (ITプロジェクトの見積もり:ソフトウェアコスト見積もり実践ガイド)

HM


ニュースから
In the News

Laurianne McLaughlin, Benjamin Alfonsi

IEEE Software, Vol. 22, No. 1, pp. 98-101 , January/February 2005

Keywords: Cybercorps, information assurance and security, software engineering education, open standards, information technology, open source software

サイバー軍団奨学金が新世代セキュリティ指導者に出資する --- Laurianne McLaughlin

サイバー軍団(Cybercorps)プログラムは,コンピュータサイエンス専攻の優秀な学生に対して,情報保証,セキュリティの教育を行い,そのスキルを持って政府系機関に就職するよう説得することを狙っている.

自由の鐘を鳴らせ? 開発者の宣言がオープン標準を促進する --- Benjamin Alfonsi

開発者独立宣言(Developer Declaration of Independence)は,単一組織に支配されている独占的アーキテクチャやレガシーソフトウェアに対する依存からの解放を求めている.ITユーザに選択の自由を与え,全ての提供者間の相互運用性(interoperability)をもたらすことによって,最終的に更なる競争市場を実現しようとする.

HM


ウィルスが私のところにやってくる
Viruses Are Beginning to Get to Me!

Robert L. Glass

IEEE Software, Vol. 22, No. 1, pp. 104, 102-103 , January/February 2005

Keywords: software virus, spam

この数年間,猛烈な勢いのウィルス増殖が見られる.何故こんなことが起きるのか? 出来ることがあるとすれば何か?

HM

IEEE Software (IEEE) Vol.22, No.2 〜 No.6

活動を休止しておりました.


[インデックス] [前の年] [次の年]