[2012 年 7 月号] |
[技術講座]
IEEE Software Jan/Feb 2012 では、「プロフェッショナルな設計を研究する」と「アルゴリズムと今日の実践者」の二つのテーマの特集を行っています。 「プロフェッショナルな設計を研究する」では、初期の設計過程に関する研究をいくつか紹介しており、「アルゴリズムと今日の実践者」は計算能力の飛躍的向上により軽視されがちなアルゴリズムに関していくつかの研究を紹介しています。 本内容は、IEEE Software の許可の下でオージス総研が日本語に翻訳して掲載したものです。
謹んで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)宛てに電子メールでお願い致します.
Forrest Shull
1つのプロジェクトから他のプロジェクトに移ると重要な要因や大事な関係がうまく当てはまらないということが多くの研究により示されてきた. このようにソフトウェア工学において全世界で成り立つ自明な理がないということに対処することで, 健全な懐疑心が育まれ,プロジェクトの文脈で収集された測定値と対比することで主要な開発プラクティスにおいて我々が信じることの正しさを確認する方法を見出すことができるのである.
https://www.computer.org/csdl/mags/so/2012/01/mso2012010004.html
有名な著者でコンサルタントの Tom DeMarco は IEEE Software への常時寄稿家であり, 彼の視点はいつもいくつかの健全な議論を生んでいる. November/December 2011 号の彼の記事「遅れるプロジェクトは皆同じである」も例に違わず, 編集長へのレターと Computing Now ウェブサイト上のコメントの両方を招く結果となった. その会話を続けさせるために, 本号ではレターとウェブコメントの両方からの選り抜きを掲載する. あなたも議論に参加されたければ, どうぞ遠慮なく software@computer.org へ電子メールを送るか, www.computer.org/software/lateprojects でコメントしてください.
https://www.computer.org/csdl/mags/so/2012/01/mso2012010008.html
Grady Booch
複雑なシステムは, 当初は動作していた, より小さなシステムが成長したものである. ただ, 様々な理由で複雑なシステムは破たんするだろう. 小規模と大規模との間, 完全なものと欠陥があるものとの間に, 来るべきものの形を見通す何らかの人あるいは人々がいる. そのような人のことを”アーキテクト”と呼ぶ.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.17
Ina Schieferdecker
開発への労力の大部分がテストに費やされる. 品質を維持しながら継続的に妥当性確認に対する労力を削減し, テスト効率を改善しなければ, 全体のコストで競争力を保てなくなるだろう. モデルベースドテスティング (MBT) は, テストケースを自動的・体系的に生成することを目指している. 本記事では, Ina Schieferdecker 氏が MBT の技術と手法を紹介する.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.13
Anthony J. Lattanze
本記事において Anthony 氏が記している洞察はアーキテクチャに関するトレーニングよりもはるかに広いものである. この洞察はあらゆる組織のあらゆるトレーニングに当てはまるものである. 大人が最もよく学習するのは, 現実の設定で新たな情報を少しずつ適用することによってであることが研究により示されている. 課題を現実のものにするチャンスがあれば, 進歩と変化が生じる希望がある. Anthonyは私の著書の多くのパターーンを用いている. Step by Step, Involve Everyone, Just Do It, Trial Run パターンであり, トレーニングをより効果的にする方法を示している. - Linda Rising, 準編集者
https://doi.ieeecomputersociety.org/10.1109/MS.2012.12
Frank Buschmann
アーキテクチャの大家であることは, 現在のソフトウェア開発の手法とテクニックにおいてプロフェッショナルな専門的見識以上のものである. それは, 主としてアーキテクトの設計への取り組み方にある. 特に, アーキテクトは「ものとものの間にあるもの」に精いっぱい注意を払う必要がある. 例えば, コード行の間に隠れたドメイン概念, コンポーネント間の相互作用とインタフェース, さらには設計オプションの選択である. これがアーキテクトの守備範囲であり, 成功したアーキテクチャでは「間にある」ものをできるだけ早く見つけ出し, それを明示し, それらを判断しているのだ!
https://doi.ieeecomputersociety.org/10.1109/MS.2012.18
Neil Maiden
人々がどのようにプログラミングを行っているかについての研究の数に比べて, 実際の要求定義手法についての研究は少ない. そのため, 実際に人々がどのように要求を定義しているかは, 比較的知られていない. 私たちは, 簡単なユーザーストーリーを考えるところから始めて, よい要求定義に必要とされる認知プロセスについての見解を示す.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.6
Alex Baker, Visitrend
Andre van der Hoek, University of California, Irvine
Harold Ossher, IBM Research
Marian Petre, The Open University
本特集では, 初期のソフトウェア設計を研究するためのアジェンダに固定する. そして, このイントロダクションはアジェンダのための(ドライバー)および問題を概説する。ソフトウェア設計の観点からソフトウェアを見ること, 設計された成果物としてソフトウェアを理解すること, そして設計がどのようにソフトウェア・ライフサイクル全体に到達するかを考えることは以下に対して顕著な利点が得られると主張する.
・ソフトウェア設計において何が効果的なのかを理解すること
・ツールと慣習へのアプローチ
本特集では, UC アーヴィンで 2010 年に行われた「プロフェッショナルなソフトウェア設計を研究する」ワークショップにおいて参加者が異なる分析な視点から同じ専門の設計セッションを分析した成果を提供する. ワークショップでの対話は, この研究のアジェンダを(ドライブする)ために批判的にみて必要なものの例を提供する. それは, 研究者と実践者との間の経験的に(グラウンドされた)対話である.
https://www.computer.org/csdl/mags/so/2012/01/mso2012010028.html
Kumiyo Nakakoji, Software Research Associates
Yasuhiro Yamamoto, Tokyo Institute of Technology
Nobuto Matsubara, Software Research Associates
Yoshinari Shirai, NTT Corporation
設計プラクティスストリーム (DPS: Design Practice Stream) ツールは, 設計者が興味のポイントを効率的にさらに調査する為に, ホワイトボードの領域の選択や議事録内で使用される少数の用語の選択により各トピックに関連するビデオの区間を閲覧する事を支援する.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.125
Ania Dilmaghani, Oracle
Jim Dibble, Cooper
本記事で紹介する10ケの設計セッション基本ルールにより, 初期段階の設計のプロセスと出力が飛躍的に改善できる.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.124
Mary Shaw, Carnegie Mellon University
交通信号のシミュレータに関する事例より, 設計において設計空間を考慮することの利点と考慮しなかった場合のリスクを説明する.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.121
Antony Tang, Swinburne University of Technology
Hans van Vliet, University Amsterdam
ソフトウェア設計作業を研究した結果, 異なる環境下で適用する4つの典型的な戦略が判明した. 設計者は, 初期の設計判断においてこれらの戦略を考慮することができる.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.130
John Rooksby, University of St. Andrews
Nozomi Ikeya, Keio University
本記事では, ホワイトボードで共同作業を行う際に開発者が連携し, 焦点を外さないために行っていることを分析している.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.123
Giuseppe Prencipe, University of Pisa
Cesare Zavattari, CrowdEngineering, Pisa
Alessandro Tommasi, CrowdEngineering, Pisa
John Favaro, Intecs SpA
計算能力とプログラミング環境の飛躍的な進歩により, ソフトウェア工学の土台となる柱の1つであるアルゴリズムの重要性が霞んでしまった. 今日の大学のカリキュラムでさえアルゴリズムの基礎を教えるのは, 過去ソフトウェア開発者教育の中心にいたとのありきたりな信念を強化するためという口実で行われるものになり果てていることが多い. しかし, 今日でもソフトウェア工学におけるアルゴリズムの重要性は減っておらず, それを無視した結果は不必要に非効率な産業アプリケーションとしてあらゆるところで明らかである. アルゴリズムの勉強は, 今日の実践者の日々の仕事で中心的な重要性という適切な場所を再び取り戻さねばならない.
https://www.computer.org/csdl/mags/so/2012/01/mso2012010061.html
Graham Cormode, AT&T Labs Research
S. Muthukrishnan, Rutgers University
Count-Min Sketchにより, 多様なアプリケーションで多数の項目の数を驚異的な精度で並行して追跡できる.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.127
Paolo Ferragina, University of Pisa
Ugo Scaiella, University of Pisa
Tagmeは, tweet, ブログ, snippetから相互参照されたテキスト断片にすばやく正確なアノテーションを行う.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.122
John Favaro
Intecs SpA, Italy
2011年6月にIEEE Softwareの準編集者であるJohn Favaro は検索エンジン界の巨人YahooのチーフアーキテクトであるDavid Chaiken 氏にアルゴリズムと今日の実践者についてのインタビューを行った. Chaiken 氏は, ソフトウェア開発者が絶えず学び直していると思われる, 時を超えた一連の原則を強調する“Architecture at Internet Scale”という基調講演をSATURN 2011で行った.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.7
Les Hatton and Michiel van Genuchten
プロフェッショナルなソフトウェア設計の研究特集を補うために, 経験を積んだマネージャーやアーキテクトである, これまでのインパクトコラムのすべての著者を対象に行ったオンライ調査の結果を示す. 本トピックスに対する実践者の意見として早期の設計判断に誰が関与すべきか, どんなツールが使われたか, 典型的な間違いについて論じる.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.5
Irwin Kwan, Oregon State University
Marcelo Cataldo, Robert Bosch Corporate Research
Daniela Damian, University of Victoria
反映仮説とも呼ばれるコンウェイの法則は, 組織がその組織のコミュニケーション構造を反映するようにシステムを設計してしまうということを予言するものである. 物理的なシステムではアーキテクチャとコミュニケーションが揃ったものになるが, ソフトウェアシステムは必ずしもそうならない. 本記事では, コンウェイの法則をタスクレベルで捉えることでソフトウェアシステムを揃えることに利点を生じることを示す.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.3
Diomidis Spinellis
行き当りばったりの方法でリファクタリングを行うと, 行えるリファクタリングの範囲が増え, 様々な言語で同じアプローチが使えるようになり, リファクタリングを行う機会に 気づくことなる. 1つのファイルでリファクタリングを行うための基本ツールは, 正規表現とエディターの置換コマンドである. 1つのディレクトリまたはプロジェクトの全ファイルに置換コマンドを適用するためには, ストリームエディターsedを使うことができる. PerlやRubyのようなスクリプト言語では, しばしばコマンドラインからの呼び出しオプションでインラインの置換機能が提供されており, それらのエクスプレッション評価機能によりもっと複雑処理を行うことができる. 最後に, findを使って対応するファイルの所在を求め, sedにより行いたいアクションを達成するためのコマンド文を作ることで, 簡単にファイル名を変えたり, ファイルを移動したりすることができる. エクスプレッションをインクリメンタルに作り, 静寂と雑音を許容し, 一貫性のあるコードを書くことにより, 本アプローチにおける効果を高めることができる.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.14
© 2012 OGIS-RI Co., Ltd. |
|