ObjectSquare [2012 年 7 月号]

[技術講座]


IEEE Software January/February 2012 目次と要旨(日本語訳)

翻訳:オブジェクトの広場

IEEE Software Jan/Feb 2012 では、「プロフェッショナルな設計を研究する」と「アルゴリズムと今日の実践者」の二つのテーマの特集を行っています。 「プロフェッショナルな設計を研究する」では、初期の設計過程に関する研究をいくつか紹介しており、「アルゴリズムと今日の実践者」は計算能力の飛躍的向上により軽視されがちなアルゴリズムに関していくつかの研究を紹介しています。 本内容は、IEEE Software の許可の下でオージス総研が日本語に翻訳して掲載したものです。



IEEE Software

私たちの使命: 先導的なソフトウェアの実践者のコミュニティを作るために, IEEE Software誌は迅速な技術の変化についていかなければならない思慮深い開発者やマネージャーに対して先進的なアイデアや専門家の分析,確かなアドバイス,思慮深い洞察を提供します. ソフトウェアの理論を実践へと翻訳するオーソリティです.

January/February 2012 (Vol. 29, No. 1):プロフェショナルな設計/今日の実践者のためのアルゴリズム

謹んでIEEE Software January/February 2012 (Vol. 29, No. 1) 号の目次と要旨をお送りします. 各号では無償の記事(英語)やポッドキャスト(英語)がいくつか提供されており, それらは要旨の下のリンクから入手することができます. 有償の技術的な記事を入手するために, 英語の印刷版[www.computer.org/subscribe/sw-jp], またはデジタル版[www.qMags.com/ISW/jp]を購読することができます.お問い合わせは, 編集長であるBrian Brannon (bbrannon@computer.org)宛てに電子メールでお願い致します.

目次

編集長から (FROM THE EDITOR)
信じるぞ! (I Believe!)

Forrest Shull

1つのプロジェクトから他のプロジェクトに移ると重要な要因や大事な関係がうまく当てはまらないということが多くの研究により示されてきた. このようにソフトウェア工学において全世界で成り立つ自明な理がないということに対処することで, 健全な懐疑心が育まれ,プロジェクトの文脈で収集された測定値と対比することで主要な開発プラクティスにおいて我々が信じることの正しさを確認する方法を見出すことができるのである.
http://www.computer.org/csdl/mags/so/2012/01/mso2012010004.html

レター (Letters)
遅れるプロジェクトは皆同じである (All Late Projects Are the Same)

有名な著者でコンサルタントの Tom DeMarco は IEEE Software への常時寄稿家であり, 彼の視点はいつもいくつかの健全な議論を生んでいる. November/December 2011 号の彼の記事「遅れるプロジェクトは皆同じである」も例に違わず, 編集長へのレターと Computing Now ウェブサイト上のコメントの両方を招く結果となった. その会話を続けさせるために, 本号ではレターとウェブコメントの両方からの選り抜きを掲載する. あなたも議論に参加されたければ, どうぞ遠慮なく software@computer.org へ電子メールを送るか, www.computer.org/software/lateprojects でコメントしてください.
http://www.computer.org/csdl/mags/so/2012/01/mso2012010008.html

アーキテクチャについて (ON ARCHITECTURE)
プロフェッショナルアーキテクト (The Professional Architect)

Grady Booch

複雑なシステムは, 当初は動作していた, より小さなシステムが成長したものである. ただ, 様々な理由で複雑なシステムは破たんするだろう. 小規模と大規模との間, 完全なものと欠陥があるものとの間に, 来るべきものの形を見通す何らかの人あるいは人々がいる. そのような人のことを”アーキテクト”と呼ぶ.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.17

ソフトウェア技術 (Software Technology)
モデルベーステスティング (Model-Based Testing)

Ina Schieferdecker

開発への労力の大部分がテストに費やされる. 品質を維持しながら継続的に妥当性確認に対する労力を削減し, テスト効率を改善しなければ, 全体のコストで競争力を保てなくなるだろう. モデルベースドテスティング (MBT) は, テストケースを自動的・体系的に生成することを目指している. 本記事では, Ina Schieferdecker 氏が MBT の技術と手法を紹介する.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.13

洞察:ソフトウェアデザイン (Insights: Software Design)
アーキテクチャ的思考を組織に注入する (Infusing Architectural Thinking into Organizations)

Anthony J. Lattanze

本記事において Anthony 氏が記している洞察はアーキテクチャに関するトレーニングよりもはるかに広いものである. この洞察はあらゆる組織のあらゆるトレーニングに当てはまるものである. 大人が最もよく学習するのは, 現実の設定で新たな情報を少しずつ適用することによってであることが研究により示されている. 課題を現実のものにするチャンスがあれば, 進歩と変化が生じる希望がある. Anthonyは私の著書の多くのパターーンを用いている. Step by Step, Involve Everyone, Just Do It, Trial Run パターンであり, トレーニングをより効果的にする方法を示している. - Linda Rising, 準編集者
http://doi.ieeecomputersociety.org/10.1109/MS.2012.12

現実的なアーキテクト (The Pragmatic Architect)
前人未到の地を果敢に進む (To Boldly Go Where No One Has Gone Before)

Frank Buschmann

アーキテクチャの大家であることは, 現在のソフトウェア開発の手法とテクニックにおいてプロフェッショナルな専門的見識以上のものである. それは, 主としてアーキテクトの設計への取り組み方にある. 特に, アーキテクトは「ものとものの間にあるもの」に精いっぱい注意を払う必要がある. 例えば, コード行の間に隠れたドメイン概念, コンポーネント間の相互作用とインタフェース, さらには設計オプションの選択である. これがアーキテクトの守備範囲であり, 成功したアーキテクチャでは「間にある」ものをできるだけ早く見つけ出し, それを明示し, それらを判断しているのだ!
http://doi.ieeecomputersociety.org/10.1109/MS.2012.18

要求 (Requirements)
要求は一体どのようにして書かれているのか? (Exactly How Are Requirements Written?)

Neil Maiden

人々がどのようにプログラミングを行っているかについての研究の数に比べて, 実際の要求定義手法についての研究は少ない. そのため, 実際に人々がどのように要求を定義しているかは, 比較的知られていない. 私たちは, 簡単なユーザーストーリーを考えるところから始めて, よい要求定義に必要とされる認知プロセスについての見解を示す.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.6


特集: プロフェッショナルなソフトウェア設計 (FOCUS: Professional Software Design)

ゲスト編集者による「プロフェッショナルなソフトウェア設計」入門 (Guest Editors' Introduction: Studying Professional Software Design)

Alex Baker, Visitrend
Andre van der Hoek, University of California, Irvine
Harold Ossher, IBM Research
Marian Petre, The Open University

本特集では, 初期のソフトウェア設計を研究するためのアジェンダに固定する. そして, このイントロダクションはアジェンダのための(ドライバー)および問題を概説する。ソフトウェア設計の観点からソフトウェアを見ること, 設計された成果物としてソフトウェアを理解すること, そして設計がどのようにソフトウェア・ライフサイクル全体に到達するかを考えることは以下に対して顕著な利点が得られると主張する.
・ソフトウェア設計において何が効果的なのかを理解すること
・ツールと慣習へのアプローチ
本特集では, UC アーヴィンで 2010 年に行われた「プロフェッショナルなソフトウェア設計を研究する」ワークショップにおいて参加者が異なる分析な視点から同じ専門の設計セッションを分析した成果を提供する. ワークショップでの対話は, この研究のアジェンダを(ドライブする)ために批判的にみて必要なものの例を提供する. それは, 研究者と実践者との間の経験的に(グラウンドされた)対話である.
http://www.computer.org/csdl/mags/so/2012/01/mso2012010028.html

ソフトウェア設計に反映するための思考の流れを紐解くことについて (Toward Unweaving Streams of Thought for Reflection in Professional Software Design)

Kumiyo Nakakoji, Software Research Associates
Yasuhiro Yamamoto, Tokyo Institute of Technology
Nobuto Matsubara, Software Research Associates
Yoshinari Shirai, NTT Corporation

設計プラクティスストリーム (DPS: Design Practice Stream) ツールは, 設計者が興味のポイントを効率的にさらに調査する為に, ホワイトボードの領域の選択や議事録内で使用される少数の用語の選択により各トピックに関連するビデオの区間を閲覧する事を支援する.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.125

初期段階でのコラボレーティブ設計の戦略 (Strategies for Early-Stage Collaborative Design)

Ania Dilmaghani, Oracle
Jim Dibble, Cooper

本記事で紹介する10ケの設計セッション基本ルールにより, 初期段階の設計のプロセスと出力が飛躍的に改善できる.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.124

設計空間の役割 (The Role of Design Spaces)

Mary Shaw, Carnegie Mellon University

交通信号のシミュレータに関する事例より, 設計において設計空間を考慮することの利点と考慮しなかった場合のリスクを説明する.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.121

設計戦略とソフトウェア設計の有効性 (Design Strategy and Software Design Effectiveness)

Antony Tang, Swinburne University of Technology
Hans van Vliet, University Amsterdam

ソフトウェア設計作業を研究した結果, 異なる環境下で適用する4つの典型的な戦略が判明した. 設計者は, 初期の設計判断においてこれらの戦略を考慮することができる.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.130

造形的設計におけるコラボレーション: 白板で共同作業を行う (Collaboration in Formative Design: Working Together at a Whiteboard)

John Rooksby, University of St. Andrews
Nozomi Ikeya, Keio University

本記事では, ホワイトボードで共同作業を行う際に開発者が連携し, 焦点を外さないために行っていることを分析している.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.123


特集: アルゴリズム (FOCUS: Algorithms)

ゲスト編集者による「アルゴリズムと現在の実践者」入門 (Guest Editors' Introduction: Algorithms and Today's Practitioner)

Giuseppe Prencipe, University of Pisa
Cesare Zavattari, CrowdEngineering, Pisa
Alessandro Tommasi, CrowdEngineering, Pisa
John Favaro, Intecs SpA

計算能力とプログラミング環境の飛躍的な進歩により, ソフトウェア工学の土台となる柱の1つであるアルゴリズムの重要性が霞んでしまった. 今日の大学のカリキュラムでさえアルゴリズムの基礎を教えるのは, 過去ソフトウェア開発者教育の中心にいたとのありきたりな信念を強化するためという口実で行われるものになり果てていることが多い. しかし, 今日でもソフトウェア工学におけるアルゴリズムの重要性は減っておらず, それを無視した結果は不必要に非効率な産業アプリケーションとしてあらゆるところで明らかである. アルゴリズムの勉強は, 今日の実践者の日々の仕事で中心的な重要性という適切な場所を再び取り戻さねばならない.
http://www.computer.org/csdl/mags/so/2012/01/mso2012010061.html

Count-Min Sketchでデータを近似する (Approximating Data with the Count-Min Sketch)

Graham Cormode, AT&T Labs Research
S. Muthukrishnan, Rutgers University

Count-Min Sketchにより, 多様なアプリケーションで多数の項目の数を驚異的な精度で並行して追跡できる.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.127

Wikiページでの短文の高速で正確なアノテーション (Fast and Accurate Annotation of Short Texts with Wikipedia Pages)
SASSY: 自己アーキテクティングサービス指向システムのためのフレームワーク (SASSY: A Framework for Self-Architecting Service-Oriented Systems)

Paolo Ferragina, University of Pisa
Ugo Scaiella, University of Pisa

Tagmeは, tweet, ブログ, snippetから相互参照されたテキスト断片にすばやく正確なアノテーションを行う.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.122

インタビュー (Interview)
検索における卓越性: David Chaikenへのインタビュー (Excellence in Search: An Interview with David Chaiken)

John Favaro
Intecs SpA, Italy

2011年6月にIEEE Softwareの準編集者であるJohn Favaro は検索エンジン界の巨人YahooのチーフアーキテクトであるDavid Chaiken 氏にアルゴリズムと今日の実践者についてのインタビューを行った. Chaiken 氏は, ソフトウェア開発者が絶えず学び直していると思われる, 時を超えた一連の原則を強調する“Architecture at Internet Scale”という基調講演をSATURN 2011で行った.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.7

インパクト (Impact)
早期の設計判断 (Early Design Decisions)

Les Hatton and Michiel van Genuchten

プロフェッショナルなソフトウェア設計の研究特集を補うために, 経験を積んだマネージャーやアーキテクトである, これまでのインパクトコラムのすべての著者を対象に行ったオンライ調査の結果を示す. 本トピックスに対する実践者の意見として早期の設計判断に誰が関与すべきか, どんなツールが使われたか, 典型的な間違いについて論じる.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.5

証言 (Voice of Evidence)
コンウェイの法則を再考する:タスクに基づく観点の証拠 (Conway’s Law Revisited: The Evidence for a Task-Based Perspective)

Irwin Kwan, Oregon State University
Marcelo Cataldo, Robert Bosch Corporate Research
Daniela Damian, University of Victoria

反映仮説とも呼ばれるコンウェイの法則は, 組織がその組織のコミュニケーション構造を反映するようにシステムを設計してしまうということを予言するものである. 物理的なシステムではアーキテクチャとコミュニケーションが揃ったものになるが, ソフトウェアシステムは必ずしもそうならない. 本記事では, コンウェイの法則をタスクレベルで捉えることでソフトウェアシステムを揃えることに利点を生じることを示す.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.3

仕事道具 (Tools of the Trade)
安くリファクタリングする (Refactoring on the Cheap)

Diomidis Spinellis

行き当りばったりの方法でリファクタリングを行うと, 行えるリファクタリングの範囲が増え, 様々な言語で同じアプローチが使えるようになり, リファクタリングを行う機会に 気づくことなる. 1つのファイルでリファクタリングを行うための基本ツールは, 正規表現とエディターの置換コマンドである. 1つのディレクトリまたはプロジェクトの全ファイルに置換コマンドを適用するためには, ストリームエディターsedを使うことができる. PerlやRubyのようなスクリプト言語では, しばしばコマンドラインからの呼び出しオプションでインラインの置換機能が提供されており, それらのエクスプレッション評価機能によりもっと複雑処理を行うことができる. 最後に, findを使って対応するファイルの所在を求め, sedにより行いたいアクションを達成するためのコマンド文を作ることで, 簡単にファイル名を変えたり, ファイルを移動したりすることができる. エクスプレッションをインクリメンタルに作り, 静寂と雑音を許容し, 一貫性のあるコードを書くことにより, 本アプローチにおける効果を高めることができる.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.14



記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点
記事に関するコメントがあれば併せてご記入ください。

© 2012 OGIS-RI Co., Ltd.
Prev Index Next
Prev Index Next