ObjectSquare [2013 年 1 月号]

[技術講座]


IEEE Software September/October 2012 目次と要旨(日本語訳)

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

September/October 2012 号の特集は、なんとリーンソフトウェア開発 (Lean Software Development)です! 日本と米国の自動車の生産性データの分析あり、Poppendieckさんのチュートリアルあり、ScrumとKanbanのプロジェクトデータに基づく比較ありと盛りだくさんです。



IEEE Software

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

September/October 2012 (Vol. 29, No. 5):Lean Software Development

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

目次

編集長から (FROM THE EDITOR)

今後の展望 (Looking Forward)

Forrest Shull

Forrest Shull編集長が直近の編集ボード会議で下された決断と, この出版物のデジタル版に対してもたらされるだろうワクワクするような変更について説明する. Shull氏は, IEEE Softwareがスポンサーになっている賞の最近の受賞者をも取り上げている
http://www.computer.org/csdl/mags/so/2012/05/mso2012050002.html

洞察:チーム (Insights: Teams)

なぜ我々すべてがうまくできないのか? (Why Can’t We All Play Nice?)

Linda Rising

本記事は, 偉大なチームの構築を阻み, 促進するように作用する2つの相反する力という, ステレオタイプ化やコラボレーションに関する我々の研究に基づいている. 「人」側の重要性については, 私の長いキャリアの遅くにようやく気づいた. ツール, プログラミング言語, 環境, 他のすべての技術的なものは重要であるが, "より柔らかいこと"が本当に, 本当に難しいものになりえる.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.128

インパクト (Impact)

ヒッグス粒子発見の裏にあるソフトウェア (The Software behind the Higgs Boson Discovery)

David Rousseau

本コラムで, David Rousseau氏は標準理論の要となる、捉えづらいヒッグス粒子の証拠をなんとか入手するために要した膨大なソフトウェア開発の労力を説明する. 前回のImpactコラムとともに, これに関するすべてが巨大であることに加えてアプリケーションもユニークである.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.123

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

3つの話 (Three Stories)

Grady Booch

我々は自らが作った魔法の国に住んでいる. 世の中は魔法を可能にした技術から多くの恩恵を受けているが, 世の中の多くはコンピューティングの内なる生活を知ることも気にすることもない.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.124

証拠の声 (Voice of Evidence)

リーンの証拠は何か? (What’s the Evidence for Lean?)

Tore Dybå and Helen Sharp

リーン生産の元々の概念とその広まっている解釈を実証する証拠を吟味することで, パフォーマンスの違いに対する証拠を測定したり, 解釈することに内在する難しさが明らかになる.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.126

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

リーンソフトウェア開発 (Lean Software Development)

Christof Ebert, Vector Consulting Services
Pekka Abrahamsson, Free University of Bozen-Bolzano
Nilay Oza, University of Helsinki

本特集ではリーンソフトウェア開発を取り上げている. どんな原則が価値を届け, 変化をもっともよく管理するためにそれらの原則をどのように導入すべきか?
http://www.computer.org/csdl/mags/so/2012/05/mso2012050022.html

リーンソフトウェア開発 (Lean Software Development)

リーンソフトウェア開発 : チュートリアル (Lean Software Development: A Tutorial)

Mary Poppendieck, Poppendieck.LLC
Michael A. Cusumano, Massachusetts Institute of Technology

「リーンソフトウェア開発」はここ数年でよく知られる用語となった. 本チュートリアルでは, その由来, 意味するところ, よく知られたアジャイル開発のプラクティスとの関係, 今後どのように発展していくのかについて説明する.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.107

リーンソフトウェア開発におけるフロー管理改善のためのアーキテクチャーの可視化 (Making Architecture Visible to Improve Flow Management in Lean Software Development)

Robert L. Nord and Ipek Ozkaya, Carnegie Mellon University
Raghvinder S. Sangwan, Pennsylvania State University

リーンのプラクティスは, エンドユーザへの価値のフローを改善するためにリトルの法則の原理を用い, ソフトウェア開発プロセスからムダの源泉を取り除く. リトルの法則では仕掛かり製品数とサイクルタイムの割合でスループットを定義している. スループット(あるいは生産性)を増加させるためには, 仕掛かり製品数の上限が仕事を行うために利用できるキャパシティーを超過させないで継続的にサイクルタイムを改善(つまり減少)させる必要がある. 本記事では, リーンソフトウェア管理のプラクティスでのアーキテクチャーが果たす役割に関する経験を紹介する. フィーチャーに基づく優先度の高い機能に関するアーキテクチャー上重要なタスクを重視したリリース計画により, 時間および努力の浪費へと導く状況を回避し, よりよい結果を達成することができる. リーンソフトウェア開発のプラクティスを適用することで, フィーチャーのフローのみならずアーキテクチャーのフローも管理する方法についてのよりよい実際的なガイダンスにより改善することができる.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.109

ソフトウェアプロダクト管理の課題に対するリーンな解決策 (Lean Solutions to Software Product Management Problems)

Andrey Maglyas, Uolevi Nikula, and Kari Smolander, Lappeenranta University of Technology

ソフトウェアプロダクト管理の分野が成功するプロダクトを開発する上で重要な役割を果たすが, 会社毎にそのプラクティスを独自に取り入れている. 本記事では, リーンにより組織がソフトウェアプロダクト管理で避けたり, 解決できる5つの問題を特定する.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.108

カンバン対Scrumを使う効果を定量化する:1つの事例 (Quantifying the Effect of Using Kanban versus Scrum: A Case Study)

Dag I.K. Sjøberg, University of Oslo
Anders Johnsen and Jorgen Solberg, Software Innovation

アジャイルとリーンコミュニティで様々なプロセスや手法の提唱している人達は, 有用性について多くの大胆な主張をしているものの, それらの主張を裏付ける実態調査はほとんど行われていない. 3年に渡り収集した12000をこえる作業事項から集められたデータでKanban対Scrumが明らかになる.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.110

フィーチャー指向要求工学の1つのビジネス効果 (A Business Case for Feature-Oriented Requirements Engineering)

Arnold Rudorfer, Siemens Healthcare Diagnostics
Tobias Stenzel and Gerold Herold, Siemens Healthcare

医療機器におけるソフトウェアの占める割合が増加しているため, エンジニアリングの効率性やコストパフォーマンスの課題への対処を支援することに適した要求工学のアプローチが求められている. フィーチャー指向要求工学はそのような解決策を提供する.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.106

論点/反論 (Point/Counterpoint)

リーンの価値 (The Value of Lean)

Kati Vilkki

リーン思想はソフトウェア開発に大きな進歩をもたらしている. これまで, (リソースの利用率の代わりに)フロー、マネージャーの役割、系統的なプロセス改善に特に大きく注目してきた.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.119

デザインパターン (Design Patterns)

デザインパターンの総合作用における変種を定義するためのUML拡張 (UML Extension for Defining the Interaction Variants of Design Patterns)

Keen Ngee Loo, Sai Peck Lee, and Thiam Kian Chiew, University of Malaya

単一のデザインパターン構造が複数の相互作用の変種を持ち得ることがある. これらの変種をUMLのシーケンス図の拡張として捉えることは, パターンに基づくビジュアルモデリングツールへの1歩の前進である.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.20

分散されたアプリケーション (Distributed Applications)

気候モデリングコミュニティにおける衛星観測の共有:ソフトウェアとアーキテクチャー(Sharing Satellite Observations with the Climate-Modeling Community: Software and Architecture)

Daniel J. Crichton, Chris A. Mattmann, Luca Cinquini, Amy Braverman, Duane Waliser, Michael Gunson, Andrew F. Hart, and Cameron E. Goodale, NASA Jet Propulsion Laboratory
Peter Lean, University of Reading
Jinwon Kim, University of California, Los Angeles

気候モデルの出力を衛星観測データと直接比較するためのソフトウェアインフラにより, それらのモデルをチューニングしたり, 地球の天候プロセスの理解における基本的な真理を得ることができる.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.21

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

ReqIF: ビジネスパートナー間のシームレスな要求交換フォーマット (ReqIF: Seamless Requirements Interchange Format between Business Partners)

Christof Ebert and Michael Jastram

プロジェクトのリスク, 製品の問題の主な発生源は, 貧弱だったり, 漏れがあったり, 変化したりする要求である. 多くの場合, 根本的な原因はビジネスパートナー間の協調が不十分なことにある. 本記事では, 要求定義での協調を効果的に行う方法に関する洞察を提供する. 我々は, シームレスな要求の開発と 管理のための技術である要求交換フォーマット(ReqIF)を説明する. 読者および今後コラムの著者になりうる人達から, 本記事やより詳しく知りたい技術やツールについてのご意見を頂けることを心待ちにしている.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.121

要求 (Requirements)

政治からは逃れられない (Politics Are Inescapable)

Neil Maiden

要求作業に関わる人達は自分達の作業に政治が大きな影響を及ぼすということに合意するが, 自分達の作業環境で「政治」が何を意味するのかを実際に定義できる人は少ない.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.120

商売道具 (Tools of the Trade)

私を仮想化してください (Virtualize Me)

Diomidis Spinellis

最近の仮想化技術により我々は自分自身のラップトップからクラウドのデータセンターに至るまでの範囲の設備でホスト可能な仮想マシン(VM)で基本ソフトウェアを走らせることができる. それゆえ, プログラマーが必要とするすべてのツール, アプリケーション, ライブラリを含む仮想化された開発環境を作ることが可能である. これは開発者の準備時間をスピードアップし, 規模の経済性をもたらし, 開発と稼働環境を一致させ, プラットホーム固有のツールの使用が可能になり, 組み込みシステムの開発をシンプルにする. VMを使うことで, テスト担当者は初期の環境と多様な(仮想)プラットホームへのアクセスを保証できる. システムコンポーネントとVMアプライアンスへの導入をすべてパッケージ化することで配置も簡単になる. 最後に, 運用面ではVMによりシステムにおいてアプリケーションのプロビジョニング, 保守期間, 高可用性, 災害からの復旧をより行いやすくなる.
http://doi.ieeecomputersociety.org/10.1109/MS.2012.125

ご意見箱 (Sounding Board)

ソフトウェア工学のための理論はどこにある? (Where’s the Theory for Software Engineering?)

Pontus Johnson and Mathias Ekstedt, KTH the Royal Institute of Technology
Ivar Jacobson, Peking University, Beijing

ダーウィンの自然選択説, マクスウェル方程式, 需要と供給の理論, およそ全ての確立した学術的専門分野では, 中心的な理論は何かということを非常に重視する. しかし, ソフトウェア工学ではそうなっていない. 他の多くの分野で非常に重要な概念にソフトウェア工学界が明らかに無関心である理由は何だろうか?
http://doi.ieeecomputersociety.org/10.1109/MS.2012.127



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

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