AbstractClub - 英文技術専門誌の論文・記事の和文要約
AbstractClub - 英文技術専門誌の論文・記事の和文要約 |
|
|
|
IEEE Software (IEEE) Vol.22, No.1
Warren Harrison (Portland State University)
IEEE Software, Vol. 22, No. 1, pp. 5-7 , January/February 2005
企業が従業員に特定のレビュー技法やプログラミング言語を学ぶことを求める場合，『必要な時に(just in time)』教育を行うことを確認するだろう．つまり，従業員はまさに必要なことを，まさに必要な時に学ぶ．しかし，『万一に備えた(just in case)』教育により，従業員をその分野の最新情報に精通させることに興味を示す企業はほとんどない．著者は，『職場トップ100』(Computerworld の調査に基づく)が，どのくらいの時間を教育に割いているか議論する．そして，比較的新しい教育のアプローチと，継続教育に基づく実務訓練を提案する．
HM
Dimidis Spinellis (Athens University of Economics and Business)
IEEE Software, Vol. 22, No. 1, pp. 10-13 , January/February 2005
IEEE Software の新コラムは，ソフトウェア開発と課題に対して適用するツールの相互作用を探索することを狙っている．各回のコラムは，特定のソフトウェア構築活動を，利用できるツール(商用ツール)の観点から議論する．このコラムは，我々のツールがどれほど山積みになっているのか幅広く考察し，著者が選ぶソフトウェアツールの罪トップ10を列挙する．
HM
Ian Sommerville (Lancaster University)
IEEE Software, Vol. 22, No. 1, pp. 16-23 , January/February 2005
いかなるシステムにおいても，開発に先立って，そのシステムが何をすることを想定しているのか，そのシステムを利用することで，いかにそのビジネスの，或いはお金を払う人々の目的を達成する助けとなるかについて，理解しなくてはならない．これには，アプリケーションドメイン(遠隔通信，鉄道，小口金融，ゲームなど)，システム運用上の制約，ステークホルダの具体的な機能要求，そして性能，セキュリティ，信頼性などシステムの重要な性質の理解が必要である．要求工学とは，こうした理解を促進する助けとなり，ステークホルダと開発に携わる技術者に対してシステム仕様を文書化するための，一連の構造化された活動に対してつけられた名前である． 本稿は，要求工学の基本的な活動を紹介し，ソフトウェア開発プロセスの部分としてどのように発展してきたかを議論する，短編チュートリアルである．しかし，確立された要求工学の技法に焦点を当てるよりも，むしろ変化し続けるソフトウェア工学が要求工学への新しい試みに至った経緯を議論する．そして，要求工学を他のシステム実装作業とより密接に統合してこれらの試みの達成を後押しするような，新しい技法を多数紹介する．
HM
Lars Hagge, Kathrin Lappe (Deutsches Elektronen-Synchrotron)
IEEE Software, Vol. 22, No. 1, pp. 24-31 , January/February 2005
パターン形式で要求工学(RE)の知識獲得を試みることで，実践経験レベルでの知識移行が可能になる．著者らは，プロジェクトにうまく適用されてきた，基本的なRE活動のための4つのパターンを紹介する．彼らはまた，パターンをREの経験を共有するための汎用的な手段として提案し，観察からパターンを導き出す分析手法について述べる．実践者は，この手法をオンラインパターンリポジトリを構築するための基礎として用いて，業務に携わるプロジェクトリーダ達にパターンを活用してもらうことができる．
HM
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
大市場向けの大きく複雑なソフトウェア製品の開発には，(市場から収集される)顧客要望と(開発組織内で作成される)製品要求の継続的で大量の流入を伴う．根拠の十分な設計上の意思決定を可能にするために，この2つの要求元の相互関係を明確にし，保守していくべきである．残念ながら，今日日常的に行われている手動による関連付けは，めんどうで，時間の無駄で，間違いやすい．著者らは，顧客要望と製品要求の関連付けをサポートする，言語工学に基づく実利的なアプローチを紹介する．本稿は，産業の実要求を用いた評価を含んでおり，そのような自動化サポートが迅速な関連付けを可能にすることを示す．これらのデータに基づいて，著者らはかなりの時間の節約が可能であると見込む．この結果は，明らかになった強化点とともに，ソフトウェア品質の向上と産業の要求工学にかける時間の節約を約束している．
HM
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
複雑なマルチプロジェクトの環境では，コミュニケーションが要求工学を成功させる鍵となる．情報モデルを用いると，要求工学を通してステークホルダの文書と責任を得ることができるので，この問題の助けとなる．責任が文書の，そして文書内の，原作者，レビュア，承認，変更伝達を決定する．情報モデルは，依存するプロジェクトのステークホルダが，互いに最も重要なコミュニケーションの必要性に気づくことを，効果的にそして実際的に保証する．著者は，例として Nokia Smart Traffic Products で開発された情報モデルを紹介し，そのモデルを2日間のワークショップでどのように定義したか示す．
HM
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
Susanne Kandrup (SusKan Development)
IEEE Software, Vol. 22, No. 1, pp. 52-54 , January/February 2005
良いシステムを作ることは、ユーザの真の要求を発見するための「正しい質問」をすることに依存する。 新たな知識を創造できるインタビューテクニックや異なった種類の質問は家族療法の手法が参考になる。
HT
Daniel M. Berry (University of Waterloo), Erik Kamsties (University of Duisburg-Essen)
IEEE Software, Vol. 22, No. 1, pp. 55-57 , January/February 2005
「すべての」という言葉や複数形は誤用されることで、コンピュータベースシステムの仕様書に曖昧さや他の問題を発生させる。 著者らはこれらの誤用や関連する誤用、それらが原因となって発生する曖昧さや問題点、どのようにそれらを回避するかを述べる。
HT
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
もしソフトウェアエンジニアがある技術の有効性についての科学的根拠を考慮しなかった場合、彼らは新しい技術の導入について間違った判断を下してしまうかもしれない。 根拠に基づく医療（evidence-based medicine）で用いられた手法がソフトウェア工学にも同様に適用できる。 そのような根拠に基づくソフトウェア工学（evidence-based software engineering : EBSE）はソフトウェアプロセス改善についての最新の考え方にうまく合致し、研究と実践の間にあるギャップを狭める重要な手段になりうる。 しかしながら、EBSEは実施者にとって難易度が高い。というのも現状のソフトウェア工学での研究は限られており、根拠の蓄積や評価を支援するような様式では報告されていないからである。
HT
Shari Lawrence Pfleeger (RAND)
IEEE Software, Vol. 22, No. 1, pp. 66-73 , January/February 2005
ソフトウェアプロジェクトの管理者は、良い事例やベストプラクティスを識別する目的で，リソース、ツール、技術などの様々なことについて意思決定する。 しかしこれらの決断は一般的な見識やベンダーの誇大広告ではなく、具体的な根拠に基づいて行われるべきである。 著者は、様々なタイプの根拠を調査し、それらからどのように論拠を構築するか、より効果的な意思決定を支援するためにはどのように論拠を強化するかを示す。
HT
Jason Remillard(Soluris)
IEEE Software, Vol. 22, No. 1, pp. 74-77 , January/February 2005
Soluris のソフトウェア工学グループがインスペクションプロセスの再開を決めた時，紙を使う代わりにインスペクションプロセスを自動化するためのツールを選定する必要があった．本稿では，2つのオープンソースツール Bugzilla, Codestriker と，3つの商用ツール VisualStudio .Net の CodeReview アドオン, CodeReviewer, ReviewPro を比較する．
HM
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
Webメタデータの標準の急増が、ソフトウェア工学、ソフトウェアの再利用、図書館学、知識表現などの関連する分野から重要な教訓を思い起こす機会を与えてくれる。 これらの標準を推進するのを急ぐことは、そのような教訓が見落とされる危険性を伴う。 加えて、メタデータの標準と人工知能の見かけ上の融合は相互に利益を生み出すように思われるが、同時に相互接続性や、ソフトウェアのテストの考慮、検索ツール、適当なアクセスポイントの提供といったその他の重要な問題から研究者の労力をそらしてしまうかもしれない。 この記事では様々なWebメタデータの標準を吟味し、関連する分野から得られる重要な教訓に注意するように呼びかける。
HT
June M. Verner (National ICT Australia), William M. Evanco (Drexel University)
IEEE Software, Vol. 22, No. 1, pp. 86-93 , January/February 2005
ある調査が、ほぼ完全に社内のソフトウェア開発に携わっている、大企業に属す多くのソフトウェア開発者が行ったソフトウェア開発の慣例を調べた。 その結果、成功するプロジェクトには、プロジェクトマネージャーがプロジェクトの明確なビジョンを持つ必要があり、要求が高品質でなければならず、妥当な要求が識別された後にのみ見積もりが行われるべきであることがわかる。 失敗するプロジェクトにおいては、多くの既知のソフトウェアの慣例が適用されていない。 調査したほとんどのプロジェクトは要求が明確でないまま始められた。 リスク管理は日常的に開発の一部として行われてはおらず、事後分析のレビューを日常的に行っていないため組織は彼らの過ちから学んでいない。 また、上層部の経営者にプロジェクトをうまく遂行するために必要な方法に対しての理解が不足しているように見える。
HT
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
Laurianne McLaughlin, Benjamin Alfonsi
IEEE Software, Vol. 22, No. 1, pp. 98-101 , January/February 2005
サイバー軍団奨学金が新世代セキュリティ指導者に出資する --- Laurianne McLaughlin
サイバー軍団(Cybercorps)プログラムは，コンピュータサイエンス専攻の優秀な学生に対して，情報保証，セキュリティの教育を行い，そのスキルを持って政府系機関に就職するよう説得することを狙っている．
自由の鐘を鳴らせ？ 開発者の宣言がオープン標準を促進する --- Benjamin Alfonsi
開発者独立宣言(Developer Declaration of Independence)は，単一組織に支配されている独占的アーキテクチャやレガシーソフトウェアに対する依存からの解放を求めている．ITユーザに選択の自由を与え，全ての提供者間の相互運用性(interoperability)をもたらすことによって，最終的に更なる競争市場を実現しようとする．
HM
Robert L. Glass
IEEE Software, Vol. 22, No. 1, pp. 104, 102-103 , January/February 2005
この数年間，猛烈な勢いのウィルス増殖が見られる．何故こんなことが起きるのか？ 出来ることがあるとすれば何か？
HM
IEEE Software (IEEE) Vol.22, No.2 〜 No.6
活動を休止しておりました．
リコー
AbstractClub