[前の年]

  IEEE Software (IEEE) Vol.27, No.1  

活動を休止しておりました.


  IEEE Software (IEEE) Vol.27, No.2  


後退か前進か? よいソフトウェア工学的アイデアを見通す
Regress or Progress? Seeing Good Software Engineering Ideas Through

Hakan Erdogmus (Kalemun Research)

IEEE Software, Vol. 27, No. 2, pp. 4-7 , March/April 2010

Keywords: software engineering innovation, diffusion of software innovations, adoptability of software innovations

昨今のソフトウェア工学的アイデアは,異なる状態を持つ,インクリメンタルで,スレッド化され,逆戻りするプロセスに従って成熟する.これらの状態の根底には,5つの方策(公平な対比,適切なバンドル化,効果的なブランド化,簡単なサンドボックス化,最適な抽出)が存在する.5つの方策により,価値のあるアイデアが,逆戻りすることなくより速く承認と採用へと進む.

訳注:本稿は IEEE Software 2010年1/2月号に同編集者が寄稿した,"Deja Vu: The Life of Software Engineering Ideas" の続編です.

HM


『ペアプログラミングがほんとにうまくいく方法』に対する反応
Responses to "How Pair Programming Really Works"

IEEE Software, Vol. 27, No. 2, pp. 8-9 , March/April 2010

Keywords: pair programming, software psychology, software process, programming teams, agile development

IEEE Software 2010年1/2月号の Stuart Wray の記事は,ペアプログラミングの実行を改善する4つの仕組みを紹介している.関連 Web サイト http://computingnow.computer.org/wray にて,自身の経験の寄稿,説明の肯定/否定といった,その記事に対する読者からのコメントを頂いた.弊誌投書部が読者のコメントを要約する.

HM


ソフトウェアの線路
Software Tracks

Diomidis Spinellis(Athens University of Economics and Business)

IEEE Software, Vol. 27, No. 2, pp. 10-11 , March/April 2010

Keywords: type checking , domain-specific , languages , architecture , software process , railroad track metaphor

鉄道の路線は指導とサポートを提供する.同じような扱いを私たちのソフトウェアに与える様々なツールがあります.コードの作成を助けるための主なツールは言語の型システム(type system)です.値のために(For values),型システムはそれぞれの異なるクラスのために別々の型を確立することにより私たちの助けとなる.コードのために(for code),インターフェースと抽象クラスは新しいクラスに対して機能を追加する際に,いくつかの重要なメソッドを忘れないことを保証する.ドメイン特化言語か適切に初期化されたデータ構造にて,私たちは効率的に設計者が意図したことを表現することが出来,それ以上は何も表現できない.より高いレベルでは,開かれていてよく定義された特定のインターフェースを使わせるようなアーキテクチャがソフトウェアの進歩を導くでしょう.最終的にもっともフレキシブルな線路を作る(track-laying)アプローチはツールでサポートされたソフトウェア開発プロセスです.

IR


効果的な分散型ソフトウェア開発のパターン
Patterns in Effective Distributed Software Development

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

Keywords: software engineering innovation, diffusion of software innovations, adoptability of software innovations Citation

これまでに発行された分散型ソフト開発における系統的な文献のレビューでは,より詳細なレビューが必要な30の文献を選出するという結果に終わっている.本論文ではこの詳細なレビューに関して,実行可能なDSDのプロセスモデルが含む視点と要素を特定する.また,将来の研究に対する意味を議論する.ウェブエキストラ,「分散ソフト開発の選択と分析」では,選出された30の研究に関する詳細を述べている.

MO


アジャイル性とアーキテクチャ:これらは共存できるか?
Agility and Architecture: Can They Coexist?

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

Keywords: software architecture, agile development methods, software engineering

ソフトウェアアーキテクチャは, 大きな設計管理部門, 大量のドキュメント, およびウォーターフォールの雰囲気といった側面を理由に, 多くのアジャイル指示者から言われのない非難を受けている.誰もがアーキテクトと呼ばれたがっているにも関わらずに, ソフトウェアアーキテクチャは, アジャイルでない実践, 考えたくもないこととして心に描かれている.しかし, アーキテクチャ上の問題を長い間無視する, ある種のシステムは, 壁にぶち当たり, アーキテクチャ視点の欠如により, 崩壊する.「アジャイルアーキテクチャ」というものは, 逆説, 矛盾, あるいは, 相容れないアプローチなのだろうか?ソフトウェア開発者たちは, アジャイルとアーキテクチャのアプローチを上手く共存させることにおいて, 重要な役割を等しく担っている.アジャイルのアプローチは, 一般的にはステークホルダー, 特に成果物オーナーと開発者が密接に連携するようなボトムアップ活動に対して, より強く依存している.本文献では, 危機にさらされている現実の問題を評価し, レトリック, および行動を超えて, さらに2つの文化が共存し, 必要に応じて支えあうことができることを提案する.

TS


平和的な共存:ソフトウェアアークテクチャ上でのアジャイル開発者の見解
Peaceful Coexistence: Agile Developer Perspectives on Software Architecture

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

Keywords: software architecture, agile software development

72人のIBMのソフトウェア開発者を対象に、アジャイル手法とソフトウェアアーキテクチャとの関係についての研究を行った.結果は,2つのアプローチは互換性があると示している.特に,アジャイル開発者は,対照あるいは中立というよりむしろ,アジャイルの価値を支持することが重要だというアーキテクチャ原則を改めて認識した.ソフトウェアアーキテクチャ原則と習慣のこの前向きの認識は,将来的にアジャイル手法とアーキテクチャ実践を統合する取り組みへの良い前兆である.

KF


サービス提供者としての設計者
Architects as Service Providers

Roland Faber (Siemens)

IEEE Software, Vol. 27, No. 2, pp. 33-40 , March/April 2010

Keywords: software architecture, agile development, software engineering, management, development teams, software engineering process, software process models

この論文は,アプリ開発者にサービスとしてのアーキテクチャを提供した著者の経験を記述している.この取り組みは,(特に,アジャイル開発における)アーキテクチャプロセスの実現のための効率的な方法となる.アーキテクトは,非機能的なシステムの品質の利害関係者という役割の中では,コーディング作業に参加することで開発者をサポートする.さらに,アーキテクトはプロジェクト全体期間を通じて開発者にアーキテクチャを伝える重要な役割を担う.特に,アジャイルコンテキストにおいては,設計者は開発チームから信頼を得ることが重要であり,その信頼は,開発チームに実践的な”サービス”を提案する設計者のアイデアによって得られる.アジャイルプロジェクトにおいては,顧客担当者に加えて,システムの品質に責任を持つ”アーキテクチャ責任者”を入れ,プロジェクトの機能要求と非機能要求のバランスを適切に保つことが重要だと筆者は考える.

TM


アジャイルアーキテクチャの相互作用
Agile Architecture Interactions

James Madison

IEEE Software, Vol. 27, No. 2, pp. 41-48 , March/April 2010

Keywords: agile development, enterprise architecture, software engineering, project management, team organization

最優先課題に基づいた一連の短期目標を立てることにより, アジャイル開発は短期間で価値を実現します.基本理念に基づいた長期目標を立てることで, アーキテクチャは注意深く価値を育て上げます.上記2点は, 相反しているように見えます.しかし, アジャイルプロジェクトにおけるアーキテクトは, 4つの特徴によって, 上記2点を同時に実現可能とします.すなわち, プロジェクト開始時期にアーキテクチャの方向性を定め, 具体的なアーキテクチャのタスクを導入する時期に絵コンテを用い, 取り組みがいのある問題に対して綿密な協力をする時期に全力で立ち向かい, 動作するソフトウェアがリリースされる時期に直接調査を行うのです.これには4つの重要なスキルが求められます.アーキテクチャの仕事を反復期間に基づいて分解する事, 開発におけるアーキテクチャの利点を提唱する事, プロジェクト実行時のアーキテクチャの状態を追尾する事, そして, より広範なenterprise architectureに向けて全てのアジャイルプロジェクトが貢献するように推進する事です.これらが効果的に行われた時, 両者が迅速に達成されて, ビジネスとアーキテクチャ優先度間の実践的なバランスが保たれるのです.

SA


責務駆動のアーキテクチャ
Responsibility-Driven Architecture

Stuart Blair (Outformations), Richard Watt (Outformations), Tim Cull (Thedwick)

IEEE Software, Vol. 27, No. 2, pp. 26-32 , March/April 2010

Keywords: agile, software architecture, economics, software engineering process

責務駆動のアーキテクチャでは, 誰が, いつ, どのようにしてアーキテクチャ上の決定を下すのかを探索する.著者の研究は, リアルオプション理論の視点でこの疑問に答えるために, アーキテクチャ上のデザインを改善するための, ひとつのフレームワークを提案する.それは, アジャイル開発におけるアーキテクトの, 役割と関連性を再構成する機会も提供する.

KT


失敗から学ぶ:第三回:釘と金槌(Hammers and Nails), 及び技術やデザインとの恋について
Learning from Failure, Part III: On Hammers and Nails, and Falling in Love with Technology and Design

Frank Buschmann (Siemens Corporate Technology)

IEEE Software, Vol. 27, No. 2, pp. 49-51 , March/April 2010

Keywords: design tactics, design simplicity, design quality, software, architecture

アーキテクチャはたびたび, 安直, もしくは不適切な設計の選択, 技術の濫用, 過剰設計に起因するあまりに複雑なソリューションに苦しむ.それぞれの条件や問題に対して, 「もっとも単純で, 可能なソリューションは何か?」という問いは, アーキテクトがすべき質問であり, それに答えるべきである.設計の戦術は, アーキテクトがこの難題(単純で, 経済的で, 手元にある問題を解決するために適切な設計を選択すること)を克服するために使える方法論である.

KT


グローバルソフトウェア開発のコラボレーションツール
Collaboration Tools for Global Software Engineering

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

Keywords: software engineering, collaboration, global software development

グローバルソフトウェア開発はツールのサポートを必要とします.最近の共同開発ツールや環境の調査では, それらの特徴と開発動向をまとめています.

ozk


言語としてのアーキテクチャ
Architecture as Language

Markus Volter (Itemis)

IEEE Software, Vol. 27, No. 2, pp. 56-64 , March/April 2010

Keywords:

アーキテクトは求められるアーキテクチャを表現するためのドメイン特化言語を, 要求定義プロセス中に開発してもよく, また, それらを使って要求アーキテクチャに基づいたシステムを記述してもよい.

ozk


税関システムにおけるドメイン特化言語
Domain-Specific Languages in a Customs Information System

Margus Freudenthal (Cybernetica AS)

IEEE Software, Vol. 27, No. 2, pp. 65-71 , March/April 2010

Keywords:

Cybernetica ASの税関エンジン(Customs Engine)は, ドメイン特化言語によってコンポーネント化されたプラットフォーム上に構成された, いくつかのサブシステムで成り立っており, 高度に反復的かつ再利用指向の開発手法を可能にしている.

SN


実装暗における合意:要求理解のための交渉
Handshaking with Implementation Proposals: Negotiating Requirements Understanding

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

Keywords: software engineering, requirements specification, software design, software methodologies

要求定義工学では, 仕様の実践というものに焦点を当てているが, まだ要求のやり取りを効果的に行うためのソリューションのメカニズムは見つけられていない.要求の厳しい, 顧客の要求に対する不十分なやり取りと暗黙の承認は, プロジェクトの要求を完全に理解することを難しくしてしまう.handshaking with implementation proposalsと呼ばれる交渉プロセスは, 要求が書かれた文書がほとんど無く, 開発者と顧客の距離が離れてしまっているような状況であっても, 要求のやり取りを効果的に行うために使われている.ハンドシェーキングは, 要求を理解するため, 価値を生み出す実装の判断を下すため, 安定したプロジェクトに対する基盤を確立するためのアーキテクチャの選択肢を利用する, 効果的で柔軟な手法である.この論文では, ハンドシェーキングプロセスを開発し, それを業務の実施の中に適用したことから学んだ, コミュニケーションの課題・ソリューション・教訓を記述している.

SN


相対的な依存に関する定理:より小さなモジュールに高い結合が集中する
The Theory of Relative Dependency: Higher Coupling Concentration in Smaller Modules

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

Keywords: training, continuing education, just in time, in-service

最近の研究では,より小さいモジュールにおいて欠陥が生じやすいことが,指摘されている. この論文において筆者らは,結合によって引き起される原因は,より小さなモジュールの結合に比例していると述べている仮説を定義し,検証している. この仮説は,強固な証拠によって支持されている. さらに,この結果はリファクタリングによってよりいっそうこの効果を悪化させる. この研究により,高度な首尾一貫した結果に基づいて,筆者らは経験に基づいて相対的な依存に関する定理を述べている. すなわち,大規模なソフトウェアシステムにおいて,より大きいモジュールと比べて,より小さなモジュールに比例して依存するようになる. これらの発見は二つ実践的な暗示を示している. 一つ目,我々は現在経験に支持されているメカニズムがある. これらのメカニズムはより小さなモジュールにおいて欠陥密度が高くなっているという観察結果から説明される. リソースを探したり組織の品質保証と品質管理実践を変更・修正するのをサポートするとき,実践者はこのメカニズムを証拠として使うことが出来る. 二つ目,特に,アジャイル手法に使用するものように,広範囲に渡ったプロジェクトのリファクタリングに,より小さなモジュールにおける欠陥検出活動は彼らの効率と効果をさらにも増加させる.

Saw


創造的な要求の会話
Creative Requirements Conversations

Markus Volter (Itemis)

IEEE Software, Vol. 27, No. 2, pp. 56-64 , March/April 2010

Keywords: design, creativity, collaboration, behavior change, requirements, engineering

Uscreates社(行動変革コンサルタント)はプロジェクト要求を集めるための会話を促進することができる創造的な空間を設計しています.要求が内包する空間と会話は, ミッドエセックスの移住労働者の健康と幸福の改善を目指すプロジェクトを通じて説明されています.

ozk


自動車のシステムソフトウェア
Software in Automotive Systems

Jurgen Mossinger (Robert Bosch)

IEEE Software, Vol. 27, No. 2, pp. 92-94 , March/April 2010

Keywords: software engineering, standards, best practices, automotive systems

エレクトロニクスとソフトウェアが今日の自動車システムに革新をもたらしている.産業パートナーはこれらのシステムの複雑性を解決して, 再利用を可能にするためのグローバルスタンダードを開発している.

IR


エンタープライズアーキテクチャとテクニカルアーキテクチャ
Enterprise Architecture and Technical Architecture

Grady Booch (IBM)

IEEE Software, Vol. 27, No. 2, pp. 96,95 , March/April 2010

Keywords: enterprise architecture, technical architecture, software-intensive systems

エンタープライズアーキテクチャとテクニカルアーキテクチャは関連しているが異なっているものです.エンタープライズアーキテクチャがソフトウェア集約的なシステムを用いたビジネスのアーキテクチャに焦点を当てているのに対して, テクニカルアーキテクチャは使命としているビジネスにより利用されるソフトウェア集約的なアーキテクチャに焦点を当てている.

IR


[前の年]