![[前の年]](../ICON/back.gif){kind=icon}
IEEE Software (IEEE) Vol.27, No.1
|
活動を休止しておりました．
|
IEEE Software (IEEE) Vol.27, No.2
|
Hakan Erdogmus (Kalemun Research)
IEEE Software, Vol. 27, No. 2, pp. 4-7 , March/April 2010
昨今のソフトウェア工学的アイデアは，異なる状態を持つ，インクリメンタルで，スレッド化され，逆戻りするプロセスに従って成熟する．これらの状態の根底には，5つの方策(公平な対比，適切なバンドル化，効果的なブランド化，簡単なサンドボックス化，最適な抽出)が存在する．5つの方策により，価値のあるアイデアが，逆戻りすることなくより速く承認と採用へと進む．
訳注：本稿は IEEE Software 2010年1/2月号に同編集者が寄稿した，"Deja Vu: The Life of Software Engineering Ideas" の続編です．
HM
IEEE Software, Vol. 27, No. 2, pp. 8-9 , March/April 2010
IEEE Software 2010年1/2月号の Stuart Wray の記事は，ペアプログラミングの実行を改善する4つの仕組みを紹介している．関連 Web サイト http://computingnow.computer.org/wray にて，自身の経験の寄稿，説明の肯定/否定といった，その記事に対する読者からのコメントを頂いた．弊誌投書部が読者のコメントを要約する．
HM
Diomidis Spinellis(Athens University of Economics and Business)
IEEE Software, Vol. 27, No. 2, pp. 10-11 , March/April 2010
鉄道の路線は指導とサポートを提供する．同じような扱いを私たちのソフトウェアに与える様々なツールがあります．コードの作成を助けるための主なツールは言語の型システム(type system)です．値のために(For values)，型システムはそれぞれの異なるクラスのために別々の型を確立することにより私たちの助けとなる．コードのために(for code)，インターフェースと抽象クラスは新しいクラスに対して機能を追加する際に，いくつかの重要なメソッドを忘れないことを保証する．ドメイン特化言語か適切に初期化されたデータ構造にて，私たちは効率的に設計者が意図したことを表現することが出来，それ以上は何も表現できない．より高いレベルでは，開かれていてよく定義された特定のインターフェースを使わせるようなアーキテクチャがソフトウェアの進歩を導くでしょう．最終的にもっともフレキシブルな線路を作る(track-laying)アプローチはツールでサポートされたソフトウェア開発プロセスです．
IR
Rafael Prikladnicki(Pontificia Universidade do Rio Grande do Sul), Jorge Luis Nicolas Audy(Pontificia Universidade do Rio Grande do Sul), Forrest Shull(Fraunhofer Center for Experimental Software Engineering, Maryland)
IEEE Software, Vol. 27, No. 2, pp. 12-15 , March/April 2010
これまでに発行された分散型ソフト開発における系統的な文献のレビューでは,より詳細なレビューが必要な３０の文献を選出するという結果に終わっている．本論文ではこの詳細なレビューに関して,実行可能なDSDのプロセスモデルが含む視点と要素を特定する．また,将来の研究に対する意味を議論する．ウェブエキストラ,「分散ソフト開発の選択と分析」では,選出された30の研究に関する詳細を述べている．
MO
Pekka Abrahamsson (University of Helsinki) Muhammad Ali Babar (IT University of Copenhagen) Philippe Kruchten (University of British Columbia)
IEEE Software, Vol. 27, No. 2, pp. 16-22 , March/April 2010
ソフトウェアアーキテクチャは, 大きな設計管理部門, 大量のドキュメント, およびウォーターフォールの雰囲気といった側面を理由に, 多くのアジャイル指示者から言われのない非難を受けている．誰もがアーキテクトと呼ばれたがっているにも関わらずに, ソフトウェアアーキテクチャは, アジャイルでない実践, 考えたくもないこととして心に描かれている．しかし, アーキテクチャ上の問題を長い間無視する, ある種のシステムは, 壁にぶち当たり, アーキテクチャ視点の欠如により, 崩壊する．「アジャイルアーキテクチャ」というものは, 逆説, 矛盾, あるいは, 相容れないアプローチなのだろうか？ソフトウェア開発者たちは, アジャイルとアーキテクチャのアプローチを上手く共存させることにおいて, 重要な役割を等しく担っている．アジャイルのアプローチは, 一般的にはステークホルダー, 特に成果物オーナーと開発者が密接に連携するようなボトムアップ活動に対して, より強く依存している．本文献では, 危機にさらされている現実の問題を評価し, レトリック, および行動を超えて, さらに２つの文化が共存し, 必要に応じて支えあうことができることを提案する．
TS
Davide Falessi (University of Rome Tor Vergata), Giovanni Cantone (University of Rome Tor Vergata), Salvatore Alessandro Sarcia' (Italian Ministry of Defense), Giuseppe Calavaro (IBM Software Group), Paolo Subiaco (IBM Software Group), Cristiana D'Amore (IBM Software Group)
IEEE Software, Vol. 27, No. 2, pp. 23-25 , March/April 2010
72人のIBMのソフトウェア開発者を対象に、アジャイル手法とソフトウェアアーキテクチャとの関係についての研究を行った．結果は,2つのアプローチは互換性があると示している．特に,アジャイル開発者は,対照あるいは中立というよりむしろ,アジャイルの価値を支持することが重要だというアーキテクチャ原則を改めて認識した．ソフトウェアアーキテクチャ原則と習慣のこの前向きの認識は,将来的にアジャイル手法とアーキテクチャ実践を統合する取り組みへの良い前兆である．
KF
Roland Faber (Siemens)
IEEE Software, Vol. 27, No. 2, pp. 33-40 , March/April 2010
この論文は，アプリ開発者にサービスとしてのアーキテクチャを提供した著者の経験を記述している．この取り組みは，（特に，アジャイル開発における）アーキテクチャプロセスの実現のための効率的な方法となる．アーキテクトは，非機能的なシステムの品質の利害関係者という役割の中では，コーディング作業に参加することで開発者をサポートする．さらに，アーキテクトはプロジェクト全体期間を通じて開発者にアーキテクチャを伝える重要な役割を担う．特に，アジャイルコンテキストにおいては，設計者は開発チームから信頼を得ることが重要であり，その信頼は，開発チームに実践的な”サービス”を提案する設計者のアイデアによって得られる．アジャイルプロジェクトにおいては，顧客担当者に加えて，システムの品質に責任を持つ”アーキテクチャ責任者”を入れ，プロジェクトの機能要求と非機能要求のバランスを適切に保つことが重要だと筆者は考える．
TM
James Madison
IEEE Software, Vol. 27, No. 2, pp. 41-48 , March/April 2010
最優先課題に基づいた一連の短期目標を立てることにより, アジャイル開発は短期間で価値を実現します．基本理念に基づいた長期目標を立てることで, アーキテクチャは注意深く価値を育て上げます．上記２点は, 相反しているように見えます．しかし, アジャイルプロジェクトにおけるアーキテクトは, ４つの特徴によって, 上記２点を同時に実現可能とします．すなわち, プロジェクト開始時期にアーキテクチャの方向性を定め, 具体的なアーキテクチャのタスクを導入する時期に絵コンテを用い, 取り組みがいのある問題に対して綿密な協力をする時期に全力で立ち向かい, 動作するソフトウェアがリリースされる時期に直接調査を行うのです．これには４つの重要なスキルが求められます．アーキテクチャの仕事を反復期間に基づいて分解する事, 開発におけるアーキテクチャの利点を提唱する事, プロジェクト実行時のアーキテクチャの状態を追尾する事, そして, より広範なenterprise architectureに向けて全てのアジャイルプロジェクトが貢献するように推進する事です．これらが効果的に行われた時, 両者が迅速に達成されて, ビジネスとアーキテクチャ優先度間の実践的なバランスが保たれるのです．
SA
Stuart Blair (Outformations), Richard Watt (Outformations), Tim Cull (Thedwick)
IEEE Software, Vol. 27, No. 2, pp. 26-32 , March/April 2010
責務駆動のアーキテクチャでは, 誰が, いつ, どのようにしてアーキテクチャ上の決定を下すのかを探索する．著者の研究は, リアルオプション理論の視点でこの疑問に答えるために, アーキテクチャ上のデザインを改善するための, ひとつのフレームワークを提案する．それは, アジャイル開発におけるアーキテクトの, 役割と関連性を再構成する機会も提供する．
KT
Frank Buschmann (Siemens Corporate Technology)
IEEE Software, Vol. 27, No. 2, pp. 49-51 , March/April 2010
アーキテクチャはたびたび, 安直, もしくは不適切な設計の選択, 技術の濫用, 過剰設計に起因するあまりに複雑なソリューションに苦しむ．それぞれの条件や問題に対して, 「もっとも単純で, 可能なソリューションは何か？」という問いは, アーキテクトがすべき質問であり, それに答えるべきである．設計の戦術は, アーキテクトがこの難題（単純で, 経済的で, 手元にある問題を解決するために適切な設計を選択すること）を克服するために使える方法論である．
KT
Filippo Lanubile (University of Bari) Christof Ebert (Vector Consulting Services) Rafael Prikladnicki (Pontificia Universidade do Rio Grande do Sul) Aurora Vizcaino (University of Castilla-La Mancha)
IEEE Software, Vol. 27, No. 2, pp. 52-55 , March/April 2010
グローバルソフトウェア開発はツールのサポートを必要とします．最近の共同開発ツールや環境の調査では, それらの特徴と開発動向をまとめています．
ozk
Markus Volter (Itemis)
IEEE Software, Vol. 27, No. 2, pp. 56-64 , March/April 2010
アーキテクトは求められるアーキテクチャを表現するためのドメイン特化言語を, 要求定義プロセス中に開発してもよく, また, それらを使って要求アーキテクチャに基づいたシステムを記述してもよい.
ozk
Margus Freudenthal (Cybernetica AS)
IEEE Software, Vol. 27, No. 2, pp. 65-71 , March/April 2010
Cybernetica ASの税関エンジン（Customs Engine）は, ドメイン特化言語によってコンポーネント化されたプラットフォーム上に構成された, いくつかのサブシステムで成り立っており, 高度に反復的かつ再利用指向の開発手法を可能にしている．
SN
Samuel Fricker (University of Zurich and Fuchs-Informatik AG), Tony Gorschek(Blekinge Institute of Technology), Carl Byman(ABB), Armin Schmidle(ABB Switzerland)
IEEE Software, Vol. 27, No. 2, pp. 72-80 , March/April 2010
要求定義工学では, 仕様の実践というものに焦点を当てているが, まだ要求のやり取りを効果的に行うためのソリューションのメカニズムは見つけられていない．要求の厳しい, 顧客の要求に対する不十分なやり取りと暗黙の承認は, プロジェクトの要求を完全に理解することを難しくしてしまう．handshaking with implementation proposalsと呼ばれる交渉プロセスは, 要求が書かれた文書がほとんど無く, 開発者と顧客の距離が離れてしまっているような状況であっても, 要求のやり取りを効果的に行うために使われている．ハンドシェーキングは, 要求を理解するため, 価値を生み出す実装の判断を下すため, 安定したプロジェクトに対する基盤を確立するためのアーキテクチャの選択肢を利用する, 効果的で柔軟な手法である．この論文では, ハンドシェーキングプロセスを開発し, それを業務の実施の中に適用したことから学んだ, コミュニケーションの課題・ソリューション・教訓を記述している．
SN
A. Gune- Koru (University of Maryland, Baltimore County), Khaled El Emam (University of Ottawa)
IEEE Software, Vol. 27, No. 2, pp. 81-89 , March/April 2010
最近の研究では，より小さいモジュールにおいて欠陥が生じやすいことが，指摘されている. この論文において筆者らは，結合によって引き起される原因は，より小さなモジュールの結合に比例していると述べている仮説を定義し，検証している. この仮説は，強固な証拠によって支持されている． さらに，この結果はリファクタリングによってよりいっそうこの効果を悪化させる． この研究により，高度な首尾一貫した結果に基づいて，筆者らは経験に基づいて相対的な依存に関する定理を述べている. すなわち，大規模なソフトウェアシステムにおいて，より大きいモジュールと比べて，より小さなモジュールに比例して依存するようになる. これらの発見は二つ実践的な暗示を示している． 一つ目，我々は現在経験に支持されているメカニズムがある． これらのメカニズムはより小さなモジュールにおいて欠陥密度が高くなっているという観察結果から説明される． リソースを探したり組織の品質保証と品質管理実践を変更・修正するのをサポートするとき，実践者はこのメカニズムを証拠として使うことが出来る． 二つ目，特に，アジャイル手法に使用するものように，広範囲に渡ったプロジェクトのリファクタリングに，より小さなモジュールにおける欠陥検出活動は彼らの効率と効果をさらにも増加させる.
Saw
Markus Volter (Itemis)
IEEE Software, Vol. 27, No. 2, pp. 56-64 , March/April 2010
Uscreates社(行動変革コンサルタント)はプロジェクト要求を集めるための会話を促進することができる創造的な空間を設計しています．要求が内包する空間と会話は, ミッドエセックスの移住労働者の健康と幸福の改善を目指すプロジェクトを通じて説明されています．
ozk
Jurgen Mossinger (Robert Bosch)
IEEE Software, Vol. 27, No. 2, pp. 92-94 , March/April 2010
エレクトロニクスとソフトウェアが今日の自動車システムに革新をもたらしている．産業パートナーはこれらのシステムの複雑性を解決して, 再利用を可能にするためのグローバルスタンダードを開発している．
IR
Grady Booch (IBM)
IEEE Software, Vol. 27, No. 2, pp. 96,95 , March/April 2010
エンタープライズアーキテクチャとテクニカルアーキテクチャは関連しているが異なっているものです．エンタープライズアーキテクチャがソフトウェア集約的なシステムを用いたビジネスのアーキテクチャに焦点を当てているのに対して, テクニカルアーキテクチャは使命としているビジネスにより利用されるソフトウェア集約的なアーキテクチャに焦点を当てている．
IR