ObjectSquare [2013 年 3 月号]

[技術講座]


IEEE Software November/December 2012 目次と要旨(日本語訳)

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

November/December 2012 号の特集は「技術的負債」です. 「技術的負債」という言葉は20年ほど前にWard Cunninghamにより現在我々が「リファクタリング」と呼んでいるものを技術的ではない利害関係者に説明するためのメタファーとして導入されたとのことです。 この技術的負債に関する様々な研究や調査結果が紹介されています.



IEEE Software

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

November/December 2012 (Vol. 29, No. 6):技術的負債 (Technical Debt)

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

目次

編集長より (FROM THE EDITOR)

研究2.0? (Research 2.0?)

Forrest Shull, Fraunhofer Center for Experimental Software Engineering

IEEE Softwareの編集長であるForrest Shull がエンピリカルソフトウェア工学(ESE)と, 対処しなければならない技術的ゴールと個別の測定とを結びつける拡張されたゴール-クエスチョン-メトリックス戦略(GQM+Strategies)を中心にソフトウェア工学における研究の現状について論じる. また, 本誌のIndustry Advisory Board の新メンバーとして加わったGirish Suryanarayanaを紹介する.
http://www.computer.org/csdl/mags/so/2012/05/mso2012050002.html

インパクト (Impact)

CSIカーネル: 数テラバイトの干し草の山から針を見つける (CSI Kernel: Finding a Needle in a Multiterabyte Haystack)

Clive King and Chris Beal, Oracle

我々が完全に依存している隠れたソフトウェアであるOSについてOracle 社のClive King とChris Beal が語る. OSの信頼性は高いものの, 完全なOSはない.そのため, 最近のシステムで動作するOSに何か問題が生じた時に, 必要な原因究明作業について通り一遍のことを行うや干し草の山の中から針を見つけるのと似た状況になる.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.154

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

悲しみの織機で織られた (Woven on the Loom of Sorrow)

Grady Booch, IBM

コンピューティングはかつて衝突を伴うものだった; 今やコンピューティングは戦争の道具である; コンピューティングは戦争の劇場になりつつある. その過程で, 衝突がコンピューティングを形作り, コンピューティングが戦闘の性質を変えた.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.168

要求 (Requirements)

あいまいさをいつくしむ (Cherishing Ambiguity)

Neil Maiden, City University London

要求におけるあいまいさが常に悪いとはかぎらない. 適切に使えば, 建設的に役立つものになりえる.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.152

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

技術的負債:メタファーから理論とプラクティスまで (Technical Debt: From Metaphor to Theory and Practice)

Philippe Kruchten, University of British Columbia, Vancouver
Robert L. Nord, Software Engineering Institute
Ipek Ozkaya, Software Engineering Institute

ソフトウェア開発における技術的負債というメタファーは, 現在我々が”リファクタリング”と呼んでいるものを技術的ではない利害関係者に説明しなければならかったために20年ほど前に導入された. このメタファーは広範囲の現象を記述するために用いられており, 本記事では技術的負債の状況を整理したものを示し, 技術的負債が課題に含まれている論文を紹介する.
http://www.computer.org/csdl/mags/so/2012/06/mso2012060018.html

技術的負債 (Technical Debt)

バランスを取る行為:ソフトウェア開発の実践者が技術的負債について語ったこと (A Balancing Act: What Software Practitioners Have to Say about Technical Debt)

Erin Lim, Aquatics Informatics
Nitin Taksande, Novasom
Carolyn Seaman, University of Maryland Baltimore County

ソフトウェア開発の実践者が技術的負債をどのように見ているのかを調べ, 現場レベルでの技術的負債の性質を明らかにするために, 様々な分野の35人のソフトウェア開発の実践者を対象にしたインタビュー調査を行った. この調査は, 原因, 症状, 影響を含めた技術的負債が起きる状況を理解することも目指した. さらに, 調査はソフトウェア開発の実践者が現在技術的負債にどのように対処しているかという点にも注目した. この分析は, 様々な短期的な関心事と長期的な関心事のバランスを取るという大きく, 複雑な行為の姿を描く.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.130

分散されたアジャイル, アジャイルテスト, および技術的負債 (Distributed Agile, Agile Testing, and Technical Debt)

Raja Bavani, MindTree

アジャイルチームは, 変化するビジネス環境への対応や定期的な間隔で動くソフトウェアを提供することでビジネス上の価値を創造する. それを行う際に, これらのチームはリリーススケジュールを満たすというようなビジネスニーズを満たすために設計トレードオフを行う. 技術的負債は, そのような判断やトレードオフの結果である. 技術的負債が発生すると, 保守性を向上させるために後続する反復においてアジャイルチームは設計を改善して累積した債務を完済しなければならない. これは系統的な方法で行い, その技術的負債が膨らんだり, プロジェクトに損害を与えないようにする必要がある. これを達成することは, 分散されたアジャイルプロジェクトにおける主要な課題の一つである. ソフトウェアプロジェクトにおける技術的負債の範囲は, アーキテクチャー, 設計, コード, テストスクリプトを含むすべての分野にまたがっている.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.155

アプリケーションの主要な技術的負債を見積もる (Estimating the Principal of an Application’s Technical Debt)

Bill Curtis, Jay Sappidi, and Alexandra Szynkarski, CAST Software

本記事は, 合わせて357 MLOC となる700ケのビジネスアプリケーションを横断する着技術的負債の性質を明らかにする. これらのアプリケーションをアーキテクチャーやコーディングのよいプラクティスに基づく1,200ケ以上のルールで分析した. 著者達は, 構造的な品質データから主な技術的負債を見積もるための調整可能なパラメーターを持つ公式を提示する.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.156

SQALE法により技術的負債を管理する ( Managing Technical Debt with the SQALE Method)

Jean-Louis Letouzey and Michel Ilkiewicz, Inspearit

現在, アプリケーションのソースコードにある技術負債を見積もるためのいくつかの手法を利用することができる. SQALE (software quality assessment based on life-cycle expectations) 法は, この負債を管理するための手引きを提供する. 本記事では, 大きな組織でのSQALE の設定, 利用をコーチング, 支援した経験から筆者らが学んだ, いくつかの実装上の推奨事項を提供する.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.129

論点 (Point)

コード品質に対して意味のあるメタファーとしての技術的負債 (Technical Debt as a Meaningful Metaphor for Code Quality)

Israel Gat, Cutter Consortium

技術的負債は, ソフトウェア工学の活躍の場をコード品質の定性的な評価から定量的な測定へと変える. そうすることで, ソフトウェアプロセスの効果的なガバナンスが可能になる.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.163

反論 (Counterpoint)

リスクのための有益なメタファーであるが実践が拙い (A Useful Metaphor for Risk Poorly Practiced)

Christof Ebert, Vector Consulting Services

技術的負債は, リスクとその経済的な影響に関するメタファーとして有用である. 不幸なことに, それは誇張されることが多く, 対象となる聞き手の関心をそらすような複雑な計算処理を含む.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.163

ソフトウェアレビュー (Software Reviews)

実践されている最近のピアレビュー:オープンソース開発からの教訓 (Contemporary Peer Review in Action: Lessons from Open Source Development)

Peter C. Rigby, Concordia University, Canada
Brendan Cleary, University of Victoria, Canada
Frederic Painchaud, Department of National Defence, Canada
Margaret-Anne Storey and Daniel M. German, University of Victoria, Canada

オープンソース開発では, ソフトウェア会社が採用できるような厳格であるがアジャイルなレビュープロセスが用いられている. また, 必要に応じてそのプロセスをよく知られている軽量なコラボレーションツールや負担にならない品質保証に関するメトリクスで補っている.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.24

リバースエンジニアリング (Reverse Engineering)

系統的なリバースエンジニアリング手法を用いた仕様の推定:自動車産業の応用( Specification Inference Using Systematic Reverse-Engineering Methodologies: An Automotive Industry Application)

Muzammil Shahbaz, University of Sheffield
K.C. Shashidhar, Max Planck Institute for Software Systems
Robert Eschbach, ITK-Engineering AG

リバースエンジニアリング手法により, 最近の乗り物の組み込みシステムのテストにおいて第3者のコンポーネントの隠れた振る舞いが明らかになった.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.159

ソフトウェアテスティング (software testing)

10分間でテスト計画 (The 10-Minute Test Plan)

James A. Whittaker, Google

テスト計画は補助的なソフトウェア開発成果物すべての中でおそらくもっとも軽視されているので,最小限の時間- 10分ぐらいかけよう.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.25

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

モデル駆動エンジニアリングにおける連動した進化 (Coupled Evolution in Model-Driven Engineering)

Davide Di Ruscio, Ludovico Iovino, and Alfonso Pierantonio, Universita degli Studi dell’Aquila

モデル駆動エンジニアリングでは, 広範な成果物がメタモデルに基づいている. 例えばUMLやBPMN, または企業固有のメタモデルが新しいバージョンのように, そのようなメタモデルが進化すると, その配下にある成果物はしばしば無効になる. 本記事で, 著者らはこのような依存関係を扱うための連動した進化の方法とツールの概要について説明する.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.153

商売道具 (Tools of the Trade)

APIとライブラリとコード (APIs, Libraries, and Code)

Diomidis Spinellis, Athens University of Economics and Business

アプリケーションプラットフォーム(Java EEまたは.NET)の機能を使うか, いくつかの入手可能な外部ライブラリの一つを呼び出すか, あるいは自分自身でコードを書くかの選択には多数の要因を考慮する必要がある. 自分自身でコードを書くときには, 自分でコードの品質を制御できる. 外部ライブラリの形でいくつかの選択肢が存在する場合には, まずライセンス条項を見ることから始めよう. 次に, そのライブラリやプラットフォームAPIの使いやすさとそのライブラリの自分のシステムとの互換性を判断しよう. 命名規約が異なる複数の要素は, 混乱やスタイルの誤用を広く呼び込む元になる. その他の調査すべき互換性の領域には, エラー処理, メモリ管理, マルチスレッド, そしてビルド管理が含まれる. 最後に, そのライブラリの依存性, 品質, そしてサポートを調べて調査を終えよう.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.151

ご意見箱 (Sounding Board)

技術的負債: 株主の利益はどこにある? (Technical Debt: Where Are the Shareholders’ Interests?)

Patrick Conroy, University of British Columbia

技術的負債はメタファー以上のものである. つまり, 他のビジネス債務で一般的な財務と会計の慣行を技術的負債に適用することで, 倫理的要件と法的ガバナンスの要件を満たすことだけではなく, 真の持続的な財務的利益を生み出すことができる.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.166



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

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