|
[2013 年 3 月号] |
［技術講座］
November/December 2012 号の特集は「技術的負債」です. 「技術的負債」という言葉は20年ほど前にWard Cunninghamにより現在我々が「リファクタリング」と呼んでいるものを技術的ではない利害関係者に説明するためのメタファーとして導入されたとのことです。 この技術的負債に関する様々な研究や調査結果が紹介されています.
謹んで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）宛てに電子メールでお願い致します.
Forrest Shull, Fraunhofer Center for Experimental Software Engineering
IEEE Softwareの編集長であるForrest Shull がエンピリカルソフトウェア工学(ESE)と, 対処しなければならない技術的ゴールと個別の測定とを結びつける拡張されたゴール-クエスチョン-メトリックス戦略(GQM+Strategies)を中心にソフトウェア工学における研究の現状について論じる.
また, 本誌のIndustry Advisory Board の新メンバーとして加わったGirish Suryanarayanaを紹介する.
https://www.computer.org/csdl/mags/so/2012/05/mso2012050002.html
Clive King and Chris Beal, Oracle
我々が完全に依存している隠れたソフトウェアであるOSについてOracle 社のClive King とChris Beal が語る.
OSの信頼性は高いものの, 完全なOSはない.そのため, 最近のシステムで動作するOSに何か問題が生じた時に, 必要な原因究明作業について通り一遍のことを行うや干し草の山の中から針を見つけるのと似た状況になる.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.154
Grady Booch, IBM
コンピューティングはかつて衝突を伴うものだった; 今やコンピューティングは戦争の道具である; コンピューティングは戦争の劇場になりつつある.
その過程で, 衝突がコンピューティングを形作り, コンピューティングが戦闘の性質を変えた.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.168
Neil Maiden, City University London
要求におけるあいまいさが常に悪いとはかぎらない. 適切に使えば, 建設的に役立つものになりえる.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.152
Philippe Kruchten, University of British Columbia, Vancouver
Robert L. Nord, Software Engineering Institute
Ipek Ozkaya, Software Engineering Institute
ソフトウェア開発における技術的負債というメタファーは, 現在我々が”リファクタリング”と呼んでいるものを技術的ではない利害関係者に説明しなければならかったために20年ほど前に導入された.
このメタファーは広範囲の現象を記述するために用いられており, 本記事では技術的負債の状況を整理したものを示し, 技術的負債が課題に含まれている論文を紹介する.
https://www.computer.org/csdl/mags/so/2012/06/mso2012060018.html
Erin Lim, Aquatics Informatics
Nitin Taksande, Novasom
Carolyn Seaman, University of Maryland Baltimore County
ソフトウェア開発の実践者が技術的負債をどのように見ているのかを調べ, 現場レベルでの技術的負債の性質を明らかにするために, 様々な分野の35人のソフトウェア開発の実践者を対象にしたインタビュー調査を行った.
この調査は, 原因, 症状, 影響を含めた技術的負債が起きる状況を理解することも目指した.
さらに, 調査はソフトウェア開発の実践者が現在技術的負債にどのように対処しているかという点にも注目した.
この分析は, 様々な短期的な関心事と長期的な関心事のバランスを取るという大きく, 複雑な行為の姿を描く.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.130
Raja Bavani, MindTree
アジャイルチームは, 変化するビジネス環境への対応や定期的な間隔で動くソフトウェアを提供することでビジネス上の価値を創造する.
それを行う際に, これらのチームはリリーススケジュールを満たすというようなビジネスニーズを満たすために設計トレードオフを行う.
技術的負債は, そのような判断やトレードオフの結果である.
技術的負債が発生すると, 保守性を向上させるために後続する反復においてアジャイルチームは設計を改善して累積した債務を完済しなければならない.
これは系統的な方法で行い, その技術的負債が膨らんだり, プロジェクトに損害を与えないようにする必要がある.
これを達成することは, 分散されたアジャイルプロジェクトにおける主要な課題の一つである.
ソフトウェアプロジェクトにおける技術的負債の範囲は, アーキテクチャー, 設計, コード, テストスクリプトを含むすべての分野にまたがっている.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.155
Bill Curtis, Jay Sappidi, and Alexandra Szynkarski, CAST Software
本記事は, 合わせて357 MLOC となる700ケのビジネスアプリケーションを横断する着技術的負債の性質を明らかにする.
これらのアプリケーションをアーキテクチャーやコーディングのよいプラクティスに基づく1,200ケ以上のルールで分析した.
著者達は, 構造的な品質データから主な技術的負債を見積もるための調整可能なパラメーターを持つ公式を提示する.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.156
Jean-Louis Letouzey and Michel Ilkiewicz, Inspearit
現在, アプリケーションのソースコードにある技術負債を見積もるためのいくつかの手法を利用することができる.
SQALE (software quality assessment based on life-cycle expectations) 法は, この負債を管理するための手引きを提供する.
本記事では, 大きな組織でのSQALE の設定, 利用をコーチング, 支援した経験から筆者らが学んだ, いくつかの実装上の推奨事項を提供する.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.129
Israel Gat, Cutter Consortium
技術的負債は, ソフトウェア工学の活躍の場をコード品質の定性的な評価から定量的な測定へと変える.
そうすることで, ソフトウェアプロセスの効果的なガバナンスが可能になる.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.163
Christof Ebert, Vector Consulting Services
技術的負債は, リスクとその経済的な影響に関するメタファーとして有用である.
不幸なことに, それは誇張されることが多く, 対象となる聞き手の関心をそらすような複雑な計算処理を含む.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.163
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
オープンソース開発では, ソフトウェア会社が採用できるような厳格であるがアジャイルなレビュープロセスが用いられている.
また, 必要に応じてそのプロセスをよく知られている軽量なコラボレーションツールや負担にならない品質保証に関するメトリクスで補っている.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.24
Muzammil Shahbaz, University of Sheffield
K.C. Shashidhar, Max Planck Institute for Software Systems
Robert Eschbach, ITK-Engineering AG
リバースエンジニアリング手法により, 最近の乗り物の組み込みシステムのテストにおいて第3者のコンポーネントの隠れた振る舞いが明らかになった.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.159
James A. Whittaker, Google
テスト計画は補助的なソフトウェア開発成果物すべての中でおそらくもっとも軽視されているので,最小限の時間- 10分ぐらいかけよう.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.25
Davide Di Ruscio, Ludovico Iovino, and Alfonso Pierantonio, Universita degli Studi dell’Aquila
モデル駆動エンジニアリングでは, 広範な成果物がメタモデルに基づいている.
例えばUMLやBPMN, または企業固有のメタモデルが新しいバージョンのように, そのようなメタモデルが進化すると, その配下にある成果物はしばしば無効になる.
本記事で, 著者らはこのような依存関係を扱うための連動した進化の方法とツールの概要について説明する.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.153
Diomidis Spinellis, Athens University of Economics and Business
アプリケーションプラットフォーム(Java EEまたは.NET)の機能を使うか, いくつかの入手可能な外部ライブラリの一つを呼び出すか, あるいは自分自身でコードを書くかの選択には多数の要因を考慮する必要がある.
自分自身でコードを書くときには, 自分でコードの品質を制御できる.
外部ライブラリの形でいくつかの選択肢が存在する場合には, まずライセンス条項を見ることから始めよう.
次に, そのライブラリやプラットフォームAPIの使いやすさとそのライブラリの自分のシステムとの互換性を判断しよう.
命名規約が異なる複数の要素は, 混乱やスタイルの誤用を広く呼び込む元になる.
その他の調査すべき互換性の領域には, エラー処理, メモリ管理, マルチスレッド, そしてビルド管理が含まれる.
最後に, そのライブラリの依存性, 品質, そしてサポートを調べて調査を終えよう.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.151
Patrick Conroy, University of British Columbia
技術的負債はメタファー以上のものである.
つまり, 他のビジネス債務で一般的な財務と会計の慣行を技術的負債に適用することで, 倫理的要件と法的ガバナンスの要件を満たすことだけではなく, 真の持続的な財務的利益を生み出すことができる.
https://doi.ieeecomputersociety.org/10.1109/MS.2012.166
| © 2013 OGIS-RI Co., Ltd. |
|
