IEEE Software March/April 2013 目次と要旨（日本語訳）

IEEE Software Mar/Apr 2013号の特集は、"Twin Peaks (双子の頂き）"です。 "Twin Peaks"は、相互の絡まり合う要求とアーキテクチャーのことを意味するそうです。アーキテクチャー上重大な要求やアーキテクチャー上の判断への影響、要求とアーキテクチャーのミスマッチを減らすための方法などが紹介されています。

私たちの使命: 先導的なソフトウェアの実践者のコミュニティを作ること.

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

要求とアーキテクチャーの双子の頂き (The Twin Peaks of Requirements and Architecture)

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

編集長より (FROM THE EDITOR)

エンジニアリングの価値: アーキテクチャー・ゲームからアジャイルな要求へ (Engineering Values: From Architecture Games to Agile Requirements)

IEEE Software 編集長の Forrest Shull が, ソフトウェア開発のすべての側面で, 大局的な視点を維持しながら, 専門家の原則を有し, 適用することの重要性を説明する. 彼は, 自分の見解を裏付けるために Philippe Krutchten, Ellen Gottesdiener, Mary Gorman による研究を引用する. 加えて, 彼は, IEEE Software 編集委員会に加わった Adam Welc 博士を歓迎し, 2012 年のソフトウェア工学と応用コンピューティングについてのアフリカ会議を説明する.
https://www.computer.org/csdl/mags/so/2013/02/mso2013020002.html

洞察：ソフトウェアチーム (Insights: Software Teams)

地理的に分散したアジャイルチームについてのワークショップを主導して得た教訓 (Lessons Learned from Leading Workshops about Geographically Distributed Agile Teams)

我々はアジャイルソフトウェア開発に関する著作をたくさん目にしてきた. そこでは, 要求, アーキテクチャー, 設計, コーディング, テスティングにおける新たな問題に取り組むために様々な趣向, 手法が現れている. それでも, 何らかの形のアジャイル開発を試みて失敗をしたという人達の経験に基づく実際の具体的で客観的な教訓を目にすることはまれである. メモを取る用意をして下さい! ‐ Linda Rising, 共同編集者
https://doi.ieeecomputersociety.org/10.1109/MS.2013.33

コンピューティングについて (On Computing)

マインクラフトから心に (From Minecraft to Minds)

心の計算可能性という話題は, 複雑な哲学的, 倫理的, 技術的な課題をもたらす. それらをさておき, この話題は我々をアルゴリズムの性質へと誘う. 我々はアルゴリズムに囲まれている. つまり,　コンピューティングの歴史はアルゴリズムの進歩の歴史でもある. 世の中では, アルゴリズムはコンピューティングが自ら作った不思議の一部であるが, それらの性質を理解することはコンピューティング的な思考の重要な部分である.
https://www.computer.org/csdl/mags/so/2013/02/mso2013020011.html

要求 (Requirements)

それで, 要求作業って何？ (So, What Is Requirements Work?)

要求作業は, 本当は問題解決を行うものである. その主たる機能は問題の所在と範囲を特定することであり, その後にそれらの問題に対する解決策を作り, 記述する.
https://doi.ieeecomputersociety.org/10.1109/MS.2013.35

商売道具 (Tools of the Trade)

ソフトウェアツールの調査: SPLASHパネル討論 (Software Tools Research: SPLASH Panel Discussion)

2012年10月25日にACM主催のSPLASHカンファレンスで”ソフトウェアツールの調査, 規模とスコープの問題か, コモディティー化の問題か?” というパネル討論のために6名の実践者と学者が集まった. 本コラムはセッションの記録に基づいて議論の内容をカンファレンス後に報告するものである.
https://www.computer.org/csdl/mags/so/2013/02/mso2013020016.html

ソフトウェア技術 (Software Technology)

グローバルなソフトウェア開発におけるグループ意識(Group Awareness in Global Software Engineering)

Filippo Lanubile, University of Bari
Fabio Calefato, University of Bari
Christof Ebert, Vector Consulting Services

チームの連携が不十分であることでしばしばグローバルなソフトウェア開発が難しくなる. グループ意識により, チームの信頼, 関係, 効率を改善することができる. 本コラムで, Filippo Lanubile, Fabio Calefato と私はグループ意識と連携を支援する中心的な技術とツールを調査した. 技術に対する洞察は, IEEEがスポンサーとなっているInternational Conference on Global Software Engineering (ICGSE)を含む関係するカンファレンスでの議論や発表からえたものである. 読者やカラムの著者になりうる人達から本コラムやもっと知りたい技術に関するご意見をお待ちしています. ‐ Christof Ebert
https://doi.ieeecomputersociety.org/10.1109/MS.2013.30

ゲスト編集者の導入 (Guest Editors’ Introduction)

要求とアーキテクチャーの双子の頂き（The Twin Peaks of Requirements and Architecture）

Jane Cleland-Huang, DePaul University
Robert S. Hanmer, Alcatel-Lucent
Sam Supakkul, Sabre
Mehdi Mirakhorli, DePaul University

非機能要求または, サービスレベル契約, 品質特性, 性能制約, アーキテクチャー重大な要求と言及されることが多い品質に関する関心事は, セキュリティー, 性能, 信頼性, 保守性のようなシステムレベルの特性を表現する. 機能要求とともに, これらの品質に関する関心事がシステムのアーキテクチャー設計を推進, 制約し, 慎重に考慮し, バランスを取らねばならない重大なトレードオフをもたらすことが多い. 要求とアーキテクチャーの間に存在する依存性は, 要求とアーキテクチャーの双子の頂きと述べられてきた.
https://doi.ieeecomputersociety.org/10.1109/MS.2013.39

インタビュー (Interviews)

双子の頂きを縦走する (Traversing the Twin Peaks)

本号のゲスト編集者であるMehdi Mirakhorli とJane Cleland-Huangが昨年10月に実施したインタビューで, 要求とアーキテクチャーとの絡まり合いについてソフトウェアアーキテクトとしての視点を共有しているDaniel Dvorak とJan Bosch の話を聞いた. Dvorakは, NASAのソフトウェアアーキテクチャーレビュー委員会のリーダーであり, Deep Space OneとMars Science Laboratoryを含む様々な技術開発プロジェクトや宇宙ミッションに従事してきた. Boschは, 一般的に数十万から数百万人にも及ぶ顧客が利用するSaaS (software-as-a-service)やWeb2.0のソリューションを設計し, 実装してきた豊富な経験を持つソフトウェアアーキテクトであり, アジャイル主義者である.
https://doi.ieeecomputersociety.org/10.1109/MS.2013.40

双子の頂き (Twin Peaks)

アーキテクチャー上重大な要求を特徴づける(Characterizing Architecturally Significant Requirements)

Lianping Chen, University of Limerick and Paddy Power PLC
Muhammad Ali Babar, Lancaster University and IT University of Copenhagen
Bashar Nuseibeh, University of Limerick and The Open University

様々な規模と領域に渡る90名の実践者についての実証的な調査に基づいてアーキテクチャー上重大な要求を特徴づける新たなフレームワーク.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.174

アーキテクチャー設計でフレームワークを使う節操のある方法 (A Principled Way to Use Frameworks in Architecture Design)

Humberto Cervantes, Autonomous Metropolitan University, Mexico City
Perla Velasco-Elizondo, Autonomous University of Zacatecas
Rick Kazman, University of Hawaii

アーキテクチャー設計のための全体論的なアプローチでは, トップダウンの概念と, ボトムアップの概念である実装成果物の両方を使う. それにより, 設計手法に一般的に見られる抽象的な概念と, アーキテクトが日々使う技術的な概念のミスマッチを減らす.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.175

あなたの“何を”は私の“如何に”である: システム設計における反復と階層 (Your “What” Is My “How”: Iteration and Hierarchy in System Design)

Michael W. Whalen, University of Minnesota
Andrew Gacek and Darren Cofer, Rockwell Collins
Anitha Murugesan, Mats P.E. Heimdahl, and Sanjai Rayadurgam, University of Minnesota

要求とアーキテクチャー設計は, 現在あるよりも, もっと密に足並みを揃えるべきである: つまり, 要求モデルは階層的にシステムを作ることに責任を負わねばならないし, アーキテクチャー設計の記法はシステムコンポーネントに対する要求仕様をよりよくサポートしなければならない.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.173

アーキテクチャー上の意思決定における非機能要求 (Non-functional Requirements in Architectural Decision-Making)

David Ameller and Claudia Ayala, BarcelonaTech-Universitat Politècnica de Catalunya
Jordi Cabot, École des Mines de Nantes
Xavier Franch, BarcelonaTech-Universitat Politècnica de Catalunya

ソフトウェアアーキテクトがどのようにエンジニアリングの観点から非機能要求に向き合っているのか, また非機能要求がどのように意思決定に影響を与えるのかについて取り上げているソフトウェアアーキテクトの調査報告である.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.176

ソフトウェア開発プロセス管理 (Software Development Process Management)

スイスのCredit Suisse IT への反復ライフサイクルモデルの導入 (Introducing an Iterative Life-Cycle Model at Credit Suisse IT Switzerland)

Katharina Sägesser, Credit Suisse
Bonney Joseph, Wipro Technologies
Rainer Grau, Zuhlke

大組織において, よく確立されたウォーターフォールライフサイクルモデルを反復モデルによるソフトウェア開発で補うという決断には慎重に調整された変更管理プロジェクトが求められた.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.74

(Cost Estimation)

ソフトウェア開発労力の相対見積もり: 何が問題でどのように比較するか (Relative Estimation of Software Development Effort: It Matters with What and How You Compare)

相対見積もりは類似性について偏った評価とソフトウェア開発の作業の労力の楽観的すぎる見積もりに結果として陥りかねない. エンピリカルな研究は見積もり精度の理由を説明し, 改善する方法を提示する.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.70

現実的なアーキテクト (The Pragmatic Architect)

アーキテクチャーとアジャイルさ: 結婚しているか, 離婚しているか, 単なる良い友達か? (Architecture and Agility: Married, Divorced, or Just Good Friends?)

アジャイル開発ではアーキテクチャーは必要か? アーキテクチャーはアジャイル開発が必要か? これら2つの質問は, 繰り返し議論されてきている. しばしば素晴らしい情熱を伴うが開けっぴろげな気持ちよりも特定の方向に偏っていることが非常に多い. 本号のコラムで, 著者らはこの議論により公平無私な観点を提供しようと試みている. 文化的に偏った前提を課したり, 議論する代わりに, 著者らはより開けっぴろげで中立的な質問を検討する: アーキテクチャーとプロセスの間の関係とは?
https://doi.ieeecomputersociety.org/10.1109/MS.2013.25

インパクト (Impact)

火星に宇宙船を着陸させる (Landing a Spacecraft on Mars)

火星に宇宙船を安全に着陸させるためにはどれほどのソフトウェアが必要であり, そしてそれらすべてのコードをどのように信頼できるものにできるか? 本コラムで, Gerard Holzmannは適用されたソフトウェア開発プロセスを説明している ‐ Michiel van GenuchtenとLes Hatton
https://doi.ieeecomputersociety.org/10.1109/MS.2013.32

証拠の声 (Voice of Evidence)

デザインパターン：魔法か, それとも神話か? (Design Patterns: Magic or Myth?)

デザインパターン文献のマッピング研究と二つの追加調査の組み合わせにより, "Gang of Four"のパターンが, 設計知識の伝達に有用な方法を提供すること, またその使用がよりよい設計につながることについて, 限られた経験的証拠しかないことを示している.
https://doi.ieeecomputersociety.org/10.1109/MS.2013.26

ご意見箱 (Sounding Board)

人々に権力を (Power to the People)

ソフトウェア開発チームはもはや指示と統制の世界にはもはや住まない, あるいは住みたいとは思わない. それらの人達は自己組織化し, 自分達を導く適応的で支援型で協調的なリーダーシップを望んでいる. この新世代の管理では, マネージャーが信頼の風土を築き, 意思決定へのチーム参加を促し, 革新を支援することが求められている. 簡単に言えば, マネージャーは従来の（細かい）管理を止め, 自己組織化されたチームと権力を共有しなければならない.
https://doi.ieeecomputersociety.org/10.1109/MS.2013.34