AbstractClub - 英文技術専門誌の論文・記事の和文要約


[インデックス] [前の年] [次の年]

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


編集者便り:ベストプラクティスとは一体誰が言ったのか。
From the Editor: Best Practices--Who Says?

Warren Harrison

IEEE Software, Vol. 21, No. 1, pp. 8-11 , January/February 2004

ソフトウェア開発の文脈で、ベストプラクティスという言葉をよく聞くが、現実には、有用さとは無縁とも思えるような活動に対しても無分別に使ってしまいがちである。本誌主筆は、ベストプラクティスという言葉の取りうる意味と、それがどのようにコンピュータフォレンジクス(computer forensics)調査に影響しうるか、なぜ彼はこの言葉をIEEE Softwareで使用を制限するのか、そしてこの言葉とコンセプトがコミュニティにとって有用であるための定義をどのようにして与えるかを考察する。

TS


ソフトウェア品質に対する新年の決意
New Year's Resolutions for Software Quality

Victor R. Basili, Barry Boehm, Al Davis, Watts S. Humphrey, Nancy Leveson, Nancy R. Mead, John D. Musa, David Lorge Parnas, Shari Lawrence Pfleeger, Elaine Weyuker

IEEE Software, Vol. 21, No. 1, pp. 12-13 , January/February 2004

本年の更なる進歩を決意し、ソフトウェア品質の分野における十人の著名人が、組織がソフトウェア品質を向上させるための方法ついて、自説を述べる。

TS


七つのホットなアウトソーシングプラクティス

Donald J. Reifer

IEEE Software, Vol. 21, No. 1, pp. 14-16 , January/February 2004

アウトソーシングにより、特定の業務が素早く、廉価に、そして自社よりも良質に遂行できると考えているだろうか?本稿ではこれらの仮定について考察し、アウトソーシングのための実用的な7ステップのアプローチを提案する。

TS


鼎立
Three Legs, No Wobble

Andy Hunt, Dave Thomas

IEEE Software, Vol. 21, No. 1, pp. 18-19 , January/February 2004

今月は、ソフトウェアプロジェクトが僅か3つの簡単な方法で崩壊する様を考察する。これらのせいで毎度プロジェクトは失敗するが、幸いにして3つの単純なプラクティス、即ちバージョン管理、ユニットテスト、そして自動化により、これらの害悪や他の一般的な災難からプロジェクトを救うことが出来る。著者らは、これらの何が重要かについて論じ、一般に用いられている、有用なフリーのオープンソースツールをリストアップする。

TS


継続的な設計
Continuous Design

Jim Shore

IEEE Software, Vol. 21, No. 1, pp. 20-22 , January/February 2004

プログラムの設計を連続的に改良するためにリファクタリングを用いるプロセス、即ち連続的な設計について、著者は4年間実験を行ってきた。彼は最初は懐疑的だったが、今では連続的な設計が彼のプログラム方法を変えたことを認めている。著者がどの段階で、どのように連続的な設計を用いたかを説明し、何にトライする必要があるかについて述べる。それらは即ち、自動テスト、変更に対するチームベースのアプローチ(collective code ownership(コード共同所有)など)、スケジュールのプレッシャーを受けながら、プログラムの設計を継続して評価し、改良するための合意である。本論文で著者は、この方式は、結局はより良く、シンプルで、保守性の高いコードをもたらすことを示唆している。

TS


ステークホルダーモデリングによるプロジェクト社会学の理解
Understanding Project Sociology by Modeling Stakeholders

Ian Alexander, Suzanne Robertson

IEEE Software, Vol. 21, No. 1, pp. 23-27 , January/February 2004

Ian AlexanderとSuzanne Robertsonは、ステークホルダーをプロジェクトに巻き込む方法の改良について、共同研究を行ってきた。本論文で著者らは、適切なステークホルダーを見つけ、彼らを持続的にプロジェクトへ寄与させるためのアプローチを総括する。

TS


ゲストエディターの紹介:オープンソースが如何にソフトウェア開発に影響を与えているか。
Guest Editors' Introduction: How Is Open Source Affecting Software Development?

Diomidis Spinellis, Athens University of Economics and Business Clemens Szyperski, Microsoft Research

IEEE Software, Vol. 21, No. 1, pp. 28-33 , January/February 2004

オープンソース運動はソフトウェア開発のプロセスとプロダクトに影響を与えている。ソフトウェアプロダクトは、再利用可能な要素の可用性とその柔軟性の向上の恩恵を被っているが、それと同時に、密結合と、より複雑な再利用部品間の依存性に苦しめられることもある。ソフトウェア開発プロセスも同様に、洗練されたオープンソース開発プラットフォームとツールの広範な可用性と利用や、プログラマーのコミュニティによる、類似の開発とコーディングのプラクティスの適用などにより利益を得ている。更には、文献資料としてのソースコードが、プログラマー教育の助けとなっている。しかしプロセスインテグレーションや、複数のオープンソースとプロプラエタリプロジェクトの共進化は依然として未解決のままである。

TS


オープンソースの様々な意味

Cristina Gacek, Budi Arief, University of Newcastle upon Tyne

IEEE Software, Vol. 21, No. 1, pp. 34-40 , January/February 2004

多くのソフトウェア開発の方法論が“オープンソース”と呼ばれるが、単にこのプロジェクトはオープンソースです、と言っただけでは、オープンソースがプロジェクトをサポートしていたことを正確には説明できない。学際的な視点が、オープンソースプロジェクトに共通する特徴と、プロジェクト固有の特徴を区別するのに役立つ。そしてこれらの特徴は、オープンソースプロジェクトの分類学の基盤を形成し、プロジェクトの解析や新たなプロジェクトの開始を助け、“オープンソース”という言葉が何を意味するかを理解するための出発点ともなる。

TS


オープンソースソフトウェアによるミッションクリティカルソフトウェアの開発:教訓

Jeffrey S. Norris, Jet Propulsion Laboratory Poul-Henning Kamp

IEEE Software, Vol. 21, No. 1, pp. 42-49 , January/February 2004

NASAジェット推進研究所のミッションオペレータは、地上探査機(rover)からのデータの解析や、roverへの指示のために、Science Activity Planner(SAP)を使用している。火星探査roverプロジェクトのためのSAP設計において、開発者はオープンソースソフトウェア部品を非常に頼りにした。そして、オープンソースソフトウェア部品の使用が、単にプロジェクトを予算内に収めるのを助けるだけでなく、より頑健で柔軟なツールをもたらすことに気づいた。オープンソースソフトウェア部品を考えるとき、想定ユーザがプロジェクトを様々な観点-成熟度、永続性、柔軟性-から評価するべきである。オープンソースソフトウェア部品を用いる最大の利点として、ソフトウェア部品のユーザは、その部品の開発者と強力な業務上の関係を構築し維持するべきである。

TS


オープンソースソフトウェアによる情報システムインフラストラクチャの開発
Developing an Information Systems Infrastructure with Open Source Software

Brian Fitzgerald, University of Limerick Tony Kenny, Beaumont Hospital

IEEE Software, Vol. 21, No. 1, pp. 50-55 , January/February 2004

これまでのところ、オープンソースソフトウェア(OSS)の多くは、Back-Officeのサーバ(GNU/Linux、Apacheなど)上で運用される、ユーザから遠いインフラストラクチャアプリケーションの上に配置されてきた。最近、アイルランドのBeaumont Hospitalは、総合的な情報システムインフラストラクチャの開発を始めた。これはGNU/LinuxやApacheに加えて、よりユーザに近いデスクトップ、Front-OfficeのOSSアプリケーションの展開によるものである。2段階のOSS実装において、Beaumontは5年間で3千万ユーロ以上のコスト削減を達成できるだろう。OSS展開によるコスト削減を定量化できた例は少ないことからも、Beaumontの事例の詳細情報は有用である。また、多くの場合、OSSシステムが持つ特別な機能が、製品により充実した特徴を与える。個々のOSS開発者のモティベーションについては、様々な議論がなされてきた。OSSソリューションの実装を決める組織の決断の陰に隠れてはいるが、この場合の真のモティベーションは、ビジネスとしての原則とプラグマティズムである。OSSを利用する会社は、OSSコミュニティに独自の方法で貢献することができる。つまり、Gnu/Linuxの基盤となるコードへの貢献よりも、むしろその企業の専門分野で開発されたアプリケーションを配布することで貢献が可能である。このタイプの貢献は、OSSアプリケーションを多くの分野で作り上げるという意味で、顕著なブートストラップ効果を持ちうる。このような貢献がなければ、そのアプリケーションは実現できなかっただろう。

TS


情報システム開発における、プロプライエタリからオープンソースツールへの変化
From Proprietary to Open Source Tools in Information Systems Development

Nicolochs Serrano, Sonia Calzada, Jose Mari Sarriegui, Ismael Ciordia, University of Navarra Engineering School

IEEE Software, Vol. 21, No. 1, pp. 56-58 , January/February 2004

過去10年にわたり、University of Navarra Engineering Schoolの教育管理システムは、メインフレーム環境からWindowsベースのクライアント−サーバアーキテクチャへ進化し、ついにはWeb環境へとなった。ベンダー依存性を軽減するために、本件の開発者はオープンソースソリューションをWebアプリケーションに適用し、満足の行く結果を得た。

TS


ゲームコミュニティにおける、フリーなオープンソース開発プラクティス
Free and Open Source Development Practices in the Game Community

Walt Scacchi, University of California, Irvine

IEEE Software, Vol. 21, No. 1, pp. 59-66 , January/February 2004

4つの独立したフリーなオープンソースソフトウェア開発コミュニティにおける、実証的な研究により、開発プロセスの共通タイプが少なくとも5つ見つかった。特にコンピュータゲームのコミュニティは共通プラクティス例を示す。

TS


新たなトリック:オープンソースが私のチームの仕事を変えた
New Tricks: How Open Source Changed the Way My Team Works

Stephane Lussier, Macadamian Technologies

IEEE Software, Vol. 21, No. 1, pp. 68-72 , January/February 2004

ある商用ソフトウェアチームは、X-Windows及びUnixにおけるWindows APIのオープンソース実装に貢献した。組織とコードに混沌が予想されたが、このチームは意外にも良く組織化されたコミュニティを独自の手順で作り上げた。

TS


発展途上国におけるLinux採用の経済
Economics of Linux Adoption in Developing Countries

Nir Kshetri, University of North Carolina, Greensboro

IEEE Software, Vol. 21, No. 1, pp. 74-81 , January/February 2004

1980年代から、ソフトウェア開発は、アメリカとヨーロッパのホワイトカラーを中心に専門化された秘伝の学問という位置づけから、重要でグローバルな国家経済の牽引役へと変化した。だが、財政面、生産性面での危険を覚悟で、このグローバルな変化を無視したソフトウェアマネージャや開発者もいる。なぜならばソフトウェアグローバリゼーションは、ソフトウェア開発のあらゆるレベル、フェーズにおいて、ソフトウェアを自社開発するか購入するかの決断プロセスに影響を与えるからである。本稿では、最も興味深く、物議の種となるであろう、ソフトウェアグローバリゼーションの実例を考察する。それはオープンソースソフトウェア(OSS)のOSであるLinuxの、発展途上国におけるソフトウェア開発への適用である。

TS


製品開発におけるオープンソースソフトウェアの利用:入門書
Using Open Source Software in Product Development: A Primer

Michel Ruffin, Christof Ebert, Alcatel

IEEE Software, Vol. 21, No. 1, pp. 82-86 , January/February 2004

商用製品においてオープンソースソフトウェアを使用することに関して、法律面でも重要な視点がある。リスク軽減のために、これらの事項をどのように扱うかという共通の疑問への答えを与える。

TS


Point/Counterpoint
Point/Counterpoint

Eric S. Raymond, Open Source Initiative David G. Messerschmitt, University of California, Berkeley

IEEE Software, Vol. 21, No. 1, pp. 89-91 , January/February 2004

オープンソースは、ソフトウェア工学を芸術から科学へ昇華させるために必要不可欠なステップだろうか?それともプログラマー以外のユーザや組織のニーズを満足させられないだろうか?本稿の著者らは、オープンソースの現在の状況、動向、そしてオープンソースが所期の目的を達成できるか否か、について討論を繰り広げる。

TS


仮想医学部キャンパスインターフェースのためのラピッドプロトタイピング
Rapid Prototyping for a Virtual Medical Campus Interface

Andreas Holzinger, Institute of Medical Informatics, Statistics, and Documentation, Graz University

IEEE Software, Vol. 21, No. 1, pp. 92-99 , January/February 2004

Graz大学の仮想医学部キャンパスの開発者は、厳密なスケジュールに沿って、シンプルで、素早く、高効率なプロトタイピング技法を用いてユーザインターフェースを作成し、実稼動システムを6ヶ月でリリースした。ユーザインターフェースデザインの相当初期からユーザを巻き込むことで、最終成果物の受け入れ率を向上させた。

TS


書籍紹介
Bookshelf

Philipp K. Janert, Shantha Mohan, Robert C. Larrabee

IEEE Software, Vol. 21, No. 1, pp. 104-106 , January/February 2004

Philipp K. Janertによるレビュー Stephen P. Berczuk and Brad Appleton著“ソフトウェア構成管理パターン(Software Configuration Management Patterns)”

Shantha Mohanによるレビュー Fergus O’Connell著“ハウツーサクセスプロジェクトIII:銀の弾丸(How to Run Successful Projects III: The Silver Bullet)”

Robert Larrabeeによるレビュー Luke Hohmann 著“ソフトウェアアーキテクチャを超えて:Winning Solution (Beyond Software Architecture: Creating and Sustaining Winning Solutions)の創生と維持”

TS

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


学習する組織とソフトウェア開発者
Learning Organizations and the Software Developer

Warren Harrison

IEEE Software, Vol. 21, No. 2, pp.5-7, March/April 2004

Keywords: learning organization; organizational behavior

多くのソフトウェア開発組織は学習する組織になろうと努力してきた。が、成功している例はあまりにも少ない。 どうしてだろうか? いくらかの考察から容易に学習する組織が習得すべき3段階のプロセスを見いだすことができる。

第1段階:組織が何かを学ぶ

第2段階:学んだ知識を管理する

第3段階:新しい知識により、何らかの形で組織のふるまいが変化する

HT


要件の育成
Nurturing Requirements

Dave Thomas, Andy Hunt

IEEE Software, Vol. 21, No. 2, pp.13-15, March/April 2004

Keywords: requirements; constraints; constraint-based requirements; stakeholders

実世界ではステークホルダは抱えている問題を解決することに興味があり、抽象的な開発者中心主義の要件には興味がない。 そして、ユーザは「間違って理解しているのかもしれない」「世の中が変わってしまったのかもしれない」と自分たちの考え方を完全に変えてしまう。 しかしながら、ある種の妄想のかたまりが開発コミュニティに生き残る。 そしてそれが要件であると考えている人が多い。

HT


高品質システムにおける要件の発掘の現状
Ongoing Requirements Discovery in High-Integrity Systems

Robyn R. Lutz, Ines Carmen Mikulski

IEEE Software, Vol. 21, No. 2, pp.19-25, March/April 2004

Keywords: requirements/specifications management; distribution, maintenance, and enhancement; product metrics; software and system safety; error processing

多くの高品質組込み型システムが使用されている間、新たな要件やそれに関する知識の発掘は継続して行われる。 ジェット推進研究所(Jet Propulsion Laboratory)で行われた8機の宇宙船のテストおよび運用時の異常報告は、要件を発見、解決するための4つの仕組みを明らかにした。 これらの仕組みを理解することで、テスト時に発見した異常を運用中に再発させないためのガイドラインを割り出すことができる。

HT


ERP要求工学の実践:教訓
ERP Requirements Engineering Practice: Lessons Learned

Maya Daneva

IEEE Software, Vol. 21, No. 2, pp.26-33, March/April 2004

Keywords: Requirements Process, Process Models, Process Implementation and Change, Reuse Models

企業資源計画(ERP)システムを実装している組織は、一般的な、既成の要求工学(RE)プロセスモデルを採用するケースが多くなってきている. しかし、一般的なREのモデルをライフプロセスにする問題に関する情報はほとんど存在しなていない。 この記事では、なぜ既成のプロセスを取り入れても満足できる基盤とならないのかを論じる。 著者は過去5年にわたって、ERPプロジェクトの要件を抽出し、モデリングし、検証して得られた経験を示し、典型的な問題点とそれらの解決方法を強調する。 成功への鍵は、クライアントの文脈でのREモデルの利用を計画すること、重要なRE活動をサポートするためのプロセスを取り入れることである。

HT


実行可能なユースケース:パーベイシブ(いつでもどこでも利用可能な)医療システムの要件
Executable Use Cases: Requirements for a Pervasive Health Care System

Jens Bak Jorgensen, Claus Bossen

IEEE Software, Vol. 21, No. 2, pp.34-41, March/April 2004

Keywords: Prototyping, requirements animation and execution, pervasive (ubiquitous) requirements; requirements engineering case studies and experiences

この記事には実行可能なユースケースの紹介、またそれらがデンマークの病院のための新たなパーベイシブ医療システムの要件定義でどのように適用されたかが記述されている。 EUCは新しい仕事のプロセスと提案されたコンピュータサポート案を表すため、散文、形式的なモデル、アニメーションを結合する。 それによりステークホルダは想定される仕事の業務プロセスの文脈の中から、システムの要件を対話形式で調査することができる。

HT


プロトタイプを用意せずに顧客とのミーティングを行ってはならない
Never Go to a Client Meeting without a Prototype

Michael Schrage

IEEE Software, Vol. 21, No. 2, pp.42-45, March/April 2004

Keywords: prototyping, collaboration

私たちは、共同開発がいかに正しい要件を実現するための鍵となるかということをよく聞く。 しかし、顧客と開発者はどうやって共同開発をすればよいのだろうか? 著者は自身の経験からプロトタイプと専門技術がいかにそれを実現させるかを教えてくれる。

HT


ソフトウェアに関するちょっとした知識
A Little Knowledge about Software

Diane Kelly, Terry Shepard

IEEE Software, Vol. 21, No. 2, pp.46-48, March/April 2004

Keywords: technical project management

ほとんどの組織ではソフトウェアは重要な役割を担っているにもかかわらず、ソフトウェア畑でない管理者はその生産とサポートについてほとんど理解していない。 今のところ、ソフトウェアが彼らの利益に直接貢献することを評価している者は少数だ。 それどころか,彼らの目の前にソフトウェアが現れた場合でも、厄介ごとや費用のかかりすぎるものとしか捉えていない。 組織にとってより深刻な問題はこのような管理者が、ソフトウェアを扱うスキルが彼ら自身の競争力をいかに改善してくれるかを認識できていないことだ。 このコラムでは、事業が提供するサービスや製品が高度に専門的な仕事に依存しているいくつかの状況を組合わせた例を見ることができる。 そして著者はそれを行うより良い方法を推薦してくれる。

HT


分散システムに動的な進化を取り入れる
Embracing Dynamic Evolution in Distributed Systems

Kam Hay Fung, Graham Low, Pradeep Kumar Ray

IEEE Software, Vol. 21, No. 2, pp.49-55, March/April 2004

Keywords: dynamic evolution, reconfigurable system, distributed system, dependable system, component-based software engineering, software maintenance

ダイナミックな進化は、停止することなく変更を受ける分散システムでは重要な事象である。 いくつかの技術はダイナミックな進化を支援するために利用できるが、このプロセスを十分に活用するためには既存のソフトウェア工学の方法論は拡張される必要がある。

HT


型付けされたイベントによる分散プログラミング
Distributed Programming with Typed Events

Patrick T. Eugster, Rachid Guerraoui

IEEE Software, Vol. 21, No. 2, pp.56-64, March/April 2004

Keywords: Distributed programming, publish-subscribe, events, type safety, Java

これまで、リモートメソッド呼び出しなどの派生物を含むリモートプロシジャーコール(RPC)の概念が、LAN上のクライアントサーバアプリケーションにとって適切なプログラミングパラダイムであることが証明されてきた。 その一方、型ベースのパブリッシュ/サブスクライブ(TPS)が、大規模でモバイルなネットワーク環境で動作する疎結合で完全に分散したアプリケーションのためのプログラミング概念として魅力的な候補に挙がっている。 TPSは疎結合化や拡張性を提供する(RPCにはない)と同時に、タイプセーフ、隠蔽性(RPCと同様)を強化する。 JavaへTPSを実装するふたつの手法が、このアプローチの可能性を見せてくれる。 ひとつが独創性に富んだアプローチで、特定の基本機能をJava言語に加えたもの。 もうひとつが、特有のカスタマイズを避けて、最近のより一般的なJavaの機構によるライブラリとして実装されたものである。

HT


モジュール組み立て
Module Assembly

Martin Fowler

IEEE Software, Vol. 21, No. 2, pp.65-67, March/April 2004

Keywords: linkage, modularity, hiding, implementation

モジュール化について語られる場合、インターフェースと実装を分離することに焦点が当てられることが多い。 モジュールに関する重要なことの全てはインターフェースから明白でない実装上の秘密を隠すことである。 そうすればユーザは実装上の全ての不愉快な詳細を知ることなく、モジュールが行うことを利用できるようになる。

HT


ソフトウェアのためのシックス・シグマ
Six Sigma for Software

Richard E. Biehl

IEEE Software, Vol. 21, No. 2, pp.68-70, March/April 2004

Keywords: Six Sigma, Total Quality Management, software quality, quality improvement

シックス・シグマ運動をより良く理解するために、著者はその主な前身である総合的品質管理(Total Quality Management)を振り返る。

HT


サービス指向ソフトウェアの理解
Understanding Service-Oriented Software

Nicolas Gold, Claire Knight, Andrew Mohan, Malcolm Munro

IEEE Software, Vol. 21, No. 2, pp.71-77, March/April 2004

Keywords: Distributed/Internet-based software engineering tools and techniques; evolving Internet applications; maintainability; restructuring, reverse engineering, and reengineering

サービス指向ソフトウェアはソフトウェア開発に関する次世代の革新的なアプローチとして認められてきている。 サービス指向性はビジネスニーズの変化に対応するために新たなソフトウェアアプリケーションを迅速かつ動的に形成することを可能にする。 従って従来のアプリケーションに発生するソフトウェアの進化の問題を軽減することができる。 これらの問題で最も大きいのは変更前に既存ソフトウェアを理解する必要があるということだ。 この記事ではサービス指向ソフトウェアの自動構築を見据え、サービス指向 の文脈におけるソフトウェアの理解について議論し,潜在的な新しい問題を特定する. 著者らはサービス指向は確かに進化の問題のある面を解決する手助けとなるが、ソフトウェアを理解することは新しく潜在的により難しい役割を担うことになると結論付けている。

HT


分離原理:あるプログラミングパラダイム
The Separation Principle: A Programming Paradigm

Yasushi Kambayashi, Henry F. Ledgard

IEEE Software, Vol. 21, No. 2, pp.78-87, March/April 2004

Keywords: programming paradigm, programming style, understandability

本稿では原理として知られているプログラミングパラダイムを紹介する。 分離原理はプログラム構築に対する単純かつ自然な方法である。 分かりやすい性質と使いやすさにより、多くの異なるソフトウェア設計が実装しやすい。 予備調査により、このプログラミングパラダイムによりプログラムの理解性が改善されることが示される。

HT


COTSに基づく開発の見落とされた側面
Overlooked Aspects of COTS-Based Development

Marco Torchiano, Maurizio Morisio

IEEE Software, Vol. 21, No. 2, pp.88-93, March/April 2004

Keywords: COTS; commercial off-the-shelf product; COTS-based development; subject matter expert

市販品を利用した開発(COTS)の研究はしばしば意見が一致せず、製品やプロジェクトの詳細に欠き、無批判に受け入れられた前提に基づいている。 この実験に基づく研究は、産業的なCOTSを基にした開発の重要な機能を確立し、それらの機能を獲得した“COTS製品”の定義を生み出した。

HT


ニュースの中から
In the News

Ashton Applewhite, Alan Davis

IEEE Software, Vol. 21, No. 2, pp.94-99, March/April 2004

ニュースの中から

とにかく、誰のバグなの:ソフトウェアの欠陥の扱いをめぐる争い

攻撃はソフトウェア・コードの脆弱性につけこむ。 それらは様々な形でやってくる:論理攻撃、トロイの木馬、ワームやウィルス、そしてそれらの変異体。 それらは多数の目的にかなう:企業スパイ活動、ホワイトカラー犯罪、社会的な“ハッカーによる政治活動”、テロ行為、悪評。 大きくなる接続性、複雑になるソフトウェア、古いプロトコルの残存が脆弱性の増長を確かなものにしている。 長時間のパッチをあてる作業が、苦しんでいるIT管理者のノルマとなっているにも関わらず、最新鋭のパッチ管理でさえ悪意のあるコードの著しい洗練化にはついていけていない。 ソフトウェアの脆弱性が発見されたときは何が起こるのだろうか? バグの報告のプロセスを指導するための合意された“ベストプラクティス”を確立するため、いくつかの企業がインターネットのセキュリティに関する団体(Organization for Internet Safety; OIS)を設立した。 さらにRFPolicyと呼ばれる非公式のガイドラインがある。それはOIS推奨と同等のオープンソースである。

南アフリカへの旅

Alan Devisは南アフリカのケープタウンにおける研究休暇中の授業について記述している

HT


本棚
Bookshelf

Deependra Moitra, Martin Fogarty

IEEE Software, Vol. 21, No. 2, pp.100-101, March/April 2004

ソフトウェア開発の教育、Deependra Moitr、レビューア

“A Handbook of Software and Systems Engineering: Empirical Observations, Laws and Theories”

『ソフトウェア/システム・エンジニアリング・ハンドブック:経験による意見、法律そして理論』

Albert Endres、Dieter Rombach著、Addison-Wesley, 2003, ISBN 0-321-15420-7, 352 pp.,US$50.00.

ユースケースを実践する人のための手引き、Martin Fogarty、レビューア

“Use Case Modeling”

『ユースケースモデリング』

Kurt Bittner、Ian Spence著、Addison-Wesley、2002, ISBN0-201-70913-9, 368 pp., US$34.99.

HT


モデリングと不快の上で
On Modeling and Discomfort

Robert L. Glass

IEEE Software, Vol. 21, No. 2, pp.104,102-103, March/April 2004

誠実な野党(Loyal Opposition)はソフトウェアモデリングに対する理論家の視点に対して反論する。

HT

IEEE Software (IEEE) Vol.21, No.3


編集者より:無知な−そして忘れっぽい
From the Editor: Clueless--and Oblivious

Warren Harrison

IEEE Software, Vol. 21, No. 3, pp.5-7, May/June 2004

ソフトウェア組織は,実際彼らがどのくらいのことを知っているかに応じて,自身の業績に対して異なる見方をしている.言い換えると,あまり得意でないことをしている人々(そして組織)は,あまり得意でないことをしているがために,しばしば自分たちのしていることを自覚していない.Warren Harrison は,心理学研究の成果をソフトウェア開発の世界に関連付ける.

HM


成功を掴む
Catching the Brass Ring

Donald J. Reifer (Reifer Consultants)

IEEE Software, Vol. 21, No. 3, pp.12-14, May/June 2004

たいていの設計組織のリーダはソフトウェア出身ではないことに気付いたことがあるだろうか?一方,私が調査した大規模ソフトウェア会社のたいていの上級役員は,工学,マーケティング,法律,そしてビジネススクールの経歴を自慢している.この部門は,どんな要因がそのような人選を支配しているのか,そしてソフトウェア工学の専門家はそれに関して何ができるのかを見る.

HM


MDA: モデラーの復讐?それともUML理想郷?
MDA: Revenge of the Modelers or UML Utopia?

Dave Thomas

IEEE Software, Vol. 21, No. 3, pp.15-17, May/June 2004

Keywords: Model Driven Architecture, MDA, Unified Modeling Language, UML

本コラムは,野心的な OMG モデル駆動型アーキテクチャ(MDA)に対して批判的な見方をする.モデル駆動のアジャイル開発は,効果的なソフトウェア開発の実践であるが,まずより広いソフトウェアコミュニティが,MDAを適切に調査,評価しない限りは,我々は世間知らずにそれを受け入れることも,無頓着にそれを拒否することもするべきではない.

HM


ソフトウェアプロダクトラインに対するROIを計算する
Calculating ROI for Software Product Lines

Gunter Bockle (Siemens), Paul Clements (Software Engineering Institute), John D. McGregor (Clemson University), Dirk Muthig, Klaus Schmid, (Fraunhofer Institute for Experimental Software Engineering)

IEEE Software, Vol. 21, No. 3, pp.23-31, May/June 2004

Keywords: software product lines, cost model, return on investment

プロダクトライン工学は,全製品集合の ROI を改善する手法となってきている.この手法は経済的な最適化に重きを置くために,ROI計算を適用する必要性が特に重要なのだ.本稿は,産業界でのプロトタイプを事例に,プロダクトラインの ROI のためのモデルについて述べる.

HM


ソフトウェアプロセス改善の ROI を計測する
Measuring the ROI of Software Process Improvement

Rini van Solingen (LogicaCMG)

IEEE Software, Vol. 21, No. 3, pp.32-38, May/June 2004

Keywords: software engineering process, process implementation and change, process measurement, return on investment, software process improvement, cost-benefit analysis, industrial case studies

ソフトウェア従事者は,ソフトウェアプロセス改善に対する投下資本利益率(ROI)計算に対する反論として,しばしばこのように聞く.『我々は SPIの利益を定量化できない.なぜなら,顧客満足度や個人の動機といった間接的な利益をお金で表すことができないから』と.SPIのための実利的なROI分析の事例において発見されたこと,およびSPIのROIに関する文献の総括に基づいて,利益を計測するある手法が提案されている.

HM


増分財源手法:データ駆動ソフトウェア開発
The Incremental Funding Method: Data-Driven Software Development

Mark Denne (Sun Microsystems Inc.), Jane Cleland-Huang (DePaul University)

IEEE Software, Vol. 21, No. 3, pp.39-47, May/June 2004

Keywords: release planning, value-based software engineering, agile development, incremental software development, requirements prioritization

この数年,1990年代後半のドットコムバブルの根源たる欠陥企業に対する熱心な調査が行われてきた.ソフトウェアへの投資は,将来の利益を見込んで,増加した企業の資産価値によって報われるというのが,当時の一般的な考え方であった.現在のIT環境は大きく変化している.組織はもはや明確な利益が見込めない限りはソフトウェア開発に投資しようとしなくなっているだけでなく,より短い期間で利益を得ることを望んでいる.これは明らかに開発コミュニティに対して,ビジネスのやり方を変えることを要求している.増分財源手法(IFM)は,データ駆動で財政的知見に基づいたソフトウェア開発手法である.IFMは,正味現在価値(NPV)を最大化し,開発上の決定が他の財政指標にどのような影響を与えるか洞察するために,機能リリースを分析して順序付ける.

HM


価値の創造と獲得:ソフトウェア開発プロセスのモデル
Value Creation and Capture: A Model of the Software Development Process

Todd Little (Landmark Graphics)

IEEE Software, Vol. 21, No. 3, pp.48-53, May/June 2004

Keywords: software economics, system dynamics, decision making, uncertainty, risk management, investment analysis, management, time estimation, cost estimation, productivity, pair programming, extreme programming, agile development, process metrics

ソフトウェア開発の力学を理解することで,管理者とプロジェクトチームメンバーは最大限に価値を提供することができる.スプレッドシート中の機能とパラメータを使い,不確実性が存在する中での価値創造と価値獲得を調査することによって,このプロセスモデルは理解を促進する.調査には,プロジェクトの人員配置,最適なリリース時期,ペアプログラミングのようなプロセス改善の潜在的影響といった項目が含まれる.

HM


ソフトウェア信頼性のROI:iDAVEモデル
The ROI of Software Dependability: The iDAVE Model

Barry Boehm, LiGuo Huang, Apurva Jain, Ray Madachy (University of Southern California)

IEEE Software, Vol. 21, No. 3, pp.54-61, May/June 2004

Keywords: benefits realization, business case analysis, cost, dependability, metrics, reliability, return on investment, software economics, value-based software engineering

情報信頼性属性値評価(iDAVE; Information Dependability Attribute Value Estimation)モデルによって,ユーザはソフトウェア信頼性への投資に対する投資収益率(ROI)を推論することができる.iDAVEは要求された信頼性属性の値を達成することによる相対的ROIを見積もり,もっとも効果的なソフトウェア信頼性戦略を選択する助けとなる.著者らは,その全般的な構造について述べ,商用注文処理システムとNASAの惑星探査車プロジェクトにおいて,信頼性に対する投資のROIを決定するのに用いた例を示す.

HM


ソフトウェア企画と設計における市場の課題
Marketplace Issues in Software Planning and Design

David G. Messerschmitt (University of California, Berkeley), Clemens Szyperski (Microsoft Research)

IEEE Software, Vol. 21, No. 3, pp.62-70, May/June 2004

Keywords: planning, risk management, schedule and organizational issues, standardization, reusable software

一般市場で売られる商用ソフトウェアにおいて,多くのソフトウェア企画と設計の意思決定は,ユーザの要求を満たすことだけではなく,さまざまな市場課題に基づいてなされている.これらの課題の多くは,3つの標準的なROIの分類である,収入,支出,リスクのいずれかに当てはめることができる.収入については,市場占有率と市場規模が相対しているが,大多数の意見は価値を増大させ(そして価格戦略を通して価値を引き出し),顧客のコスト構造を最小化するというものである.提供側のコスト構造の操作は,ソフトウェアの配布方法,反復コスト(例えば保守)の管理,ソフトウェア再利用によって決まる.ソフトウェア開発は,常に実際の収入と支出が計画から逸脱するリスクを伴っている.このリスクを管理する最も効果的な方法は,意思決定方式,知的財産管理,投資分散,そして協業を通して,プロジェクト,組織,産業の全てのレベルで統合化された手法である.

HM


ソフトウェア構築のためのタスク配分最適化装置
A Task Allocation Optimizer for Software Construction

Jim Duggan, Jason Byrne, Gerard J. Lyons (National University of Ireland, Galway)

IEEE Software, Vol. 21, No. 3, pp.76-82, May/June 2004

Keywords: software project management, scheduling, optimization

ソフトウェアプロジェクトにおける開発タスクの配分は複雑な作業である.プログラマの能力および生産性のレベルを含む,考慮すべき多くの要因が存在する.更に,全体コストや障害数といった,プロジェクトの重要な目的を最小化しなければならない.多目的最適化は進化的アルゴリズムに基づいており,相反する目的を持つ問題に対する最適解の集合を生成することができる.本稿は,この手法をうまく適用して,ソフトウェア開発チーム内のタスク配分を行う方法を示す.

HM


品質評価モデルと計測
Quality-Evaluation Models and Measurements

Jeff Tian (Southern Methodist University)

IEEE Software, Vol. 21, No. 3, pp.84-91, May/June 2004

Keywords: software quality assurance, quality evaluation models, software measurement

今日の競争市場において,品質はソフトウェア製品の成否を決定しうる.多くの品質特性の中で,いくつかの側面は機能の正当性,或いは仕様準拠を直接扱うものである.一方,他の側面はユーザビリティ,ポータビリティなどを扱う.正当性は通常もっとも重要な品質の側面である.量販市場の個人向けソフトウェアのように,新機能やユーザビリティの優位性が高い市場セグメントにおいてさえ,正当性はユーザの期待する重要な要素である.本稿は,いくつかの品質評価モデルを分類する.

HM


ソフトウェアを正す
Righting Software

James R. Larus, Thomas Ball, Manuvir Das, Robert DeLine, Manuel Fahndrich, Jon Pincus, Sriram K. Rajamani, Ramanathan Venkatapathy (Microsoft Research)

IEEE Software, Vol. 21, No. 3, pp.92-100, May/June 2004

Keywords: software engineering, coding tools and techniques, formal methods, model checking

正当性ツールは,nullポインタ参照,API使用誤り,ファイルディスクリプタの close 忘れのようなプログラミング誤りを見つけることで人間の欠点を補い,ソフトウェア開発を改善することができる.Microsoft Research は 2世代の正当性ツールを開発した.第1は,プログラミング誤りを見つけるために組織内で広く使われている発見的ツールである.第2は,プログラム健全性解析に基づき,インターフェイスの振る舞いを記述したルールによって駆動されるツールである.あわせて,これらのツールは,開発プロセスの初期の段階で,誤りを発見し修正するための体系的な手法を提供する.

HM


アジャイル要求:好機か,それとも矛盾語法か?
Agile Requirements: Opportunity or Oxymoron?

Ken Orr

IEEE Software, Vol. 21, No. 3, pp.71-73, May/June 2004

Keywords: requirements, agile development, primary outputs

アジャイル(俊敏な)開発支持者の何人かは,実はアジャイル環境において要求は必要でないと提唱しているが,本稿は全ての重要なシステムがいかに妥当な要求を必要としているかについて議論する.加えて,『要求する』とは本当はどういう意味なのか明らかにすることを試みる.

HM


知らないおかげで
On the Virtues of Not Knowing

Jane Huffman Hayes

IEEE Software, Vol. 21, No. 3, pp.74-75, May/June 2004

効果的な品質保証分析者の評価すべき特質は,他人がしばしあまりに容易に受け入れてしまうことに疑いをもつ能力である.この賞賛すべき特質は3通りに現れる.あなたの知っていることを知る,あなたがいつしないか尋ねる,そしてあなたがいつするか尋ねる.囲み記事:『生涯学習の機会』

HM


OOを1文で言うと:ドライに,シャイにしておこう,そして他の人に教えよう
OO in One Sentence: Keep It DRY, Shy, and Tell the Other Guy

Andy Hunt, Dave Thomas

IEEE Software, Vol. 21, No. 3, pp.101-103, May/June 2004

Keywords: object-oriented programming, OO

オブジェクト指向プログラミングを習得するのは難しく,時間のかかるプロセスだと感じている人がいる.しかし,そんなに頑張る必要があるか? また難しさはOOプログラミングに特有のことか? 多くのOOプログラミングの基礎は,他のプログラミングパラダイムに対しても同じように利益を与える.たとえあなたがシェルスクリプトやバッチファイルを書いているのだとしても,これらの手法を有益に使うことができる.

HM


書評
Bookshelf

Fernando Berzal, Diomidis Spinellis

IEEE Software, Vol. 21, No. 3, pp.104-105, May/June 2004

表記法とその使用について(On Notations and Their Use) Fernando Berzal:

『Design Methods For Reactive Systems(リアクティブシステムのための設計手法)』 (Roel J. Wieringa 著, Morgan Kaufmann 発行) の書評.

常套句は退屈でもあり有用でもある(Cliches Can Be Both Tiring and Helpful) Diomidis Spinellis:

『More Secrets of Consulting: The Consultant's Tool Kit(コンサルティングの更なる極意:コンサルタントのツールキット』(Gerald M. Weinberg 著) の書評.

HM


問題と解を区別することを学ぶ
Learning to Distinguish a Solution from a Problem

Robert L. Glass (Computing Trends)

IEEE Software, Vol. 21, No. 3, pp.112, 111, May/June 2004

Keywords: software maintenance

ソフトウェア保守とソフトウェア保守担当者はもっと尊敬に値する.

HM


最新標準:訂正
The Latest on Standards-Corrected

Paul Croll

IEEE Software, Vol. 21, No. 3, pp.c3, May/June 2004

ソフトウェア工学技術会議(Technical Council on Software Engineering)のソフトウェア・システム工学標準化委員会(Software and Systems Engineering Standards Committee)委員長が,委員会活動の最新情報をお届けする.

HM

IEEE Software (IEEE) Vol.21, No.4


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

IEEE Software (IEEE) Vol.21, No.5


編集者から:プロパガンダとソフトウェア開発
From the Editor: Propaganda and Software Development

Warren Harrison

IEEE Software, Vol. 21, No. 5, pp. 5-7 , September/October 2004

Keywords: software engineering, propaganda

著者は、他者にプロパガンダの研究という自分たちの仕事を認めてもらいたい革新者たちにアドバイスする。プロパガンダは軍や政党はもちろん企業でさえ利用しているものである。 我々がプロパガンダを極悪なマインドコントロールを行う陰謀や政治的な過激主義者と結びつけて考えるようになってきたにもかかわらず、実はそれが自分たちと同じように物事を見るよう他者を説得するためのちょっとしたアプローチであると彼は主張する。

HT


リアルタイムアプリケーションのためにLinuxを使う
Using Linux for Real-Time Applications

Armand Marchesin

IEEE Software, Vol. 21, No. 5, pp. 18-20 , September/October 2004

Keywords: Linux, real-time, RTLinux

このコラムでは、オープンソースのソフトウェア、コンポーネント、ツールに関するユーザの経験を共有することを奨励している。 アルカテル社(Alcatel)はOXO e-コミュニケーションサーバーのソフトウェアプラットフォームを支えるものとして,RTLinux(Real-Time Linux)の拡張を施したLinuxを採用した。 著者は彼らがどのようにLinuxを使用したかを、特にソフトウェアアーキテクチャとリアルタイム性の問題に焦点をあてて議論する。

HT


すぐに失敗する
Fail Fast

Jim Shore

IEEE Software, Vol. 21, No. 5, pp. 21-25 , September/October 2004

Keywords: fail fast

ソフトウェアのバグの数を劇的に減らすための簡単なテクニックについて学ぶ。 それは、少なくとも最初の段階での全体的なバグの量を減らすものではないが、ほとんどの欠陥を非常に発見しやすくするものである。

HT


なぜ、ソフトウェアの同業者を間引くことがよく行われるのか
Why Culling Software Colleagues Is Popular

Peter Middleton, Ho Woo Lee, Shahrukh A. Irani

IEEE Software, Vol. 21, No. 5, pp. 28-32 , September/October 2004

Keywords: software engineering process, management, variance, queuing theory

企業の財政状態が悪化したときに実施されるスタッフの削減は、一般的には楽しい任務ではないと見なされている。 この記事では、質が悪い人員は経営者が認識している損害よりも大きな損害を生む原因となるため、職場では定期的なスタッフ削減がよく行われ得るのではないかという意見を検討する。 著者は、待ち行列論とシミュレーションを用いて質の悪い仕事による深刻な影響を示す。 このような背景では、質の悪いスタッフを削減することに協賛するのは道理にかなっている。 著者は、ソフトウェア開発者がスタッフの削減により生産性を改善できると感じているかを見いだすために、彼らを調査することを薦める。 もし彼らがそう感じていると分かった場合は、“ランク付けと排除”のアプローチを実施するよく知られた任務が存在するようになるだろう。

HT


ITシステムの棚卸し:“変化のパラダイム”を支持すること
Inventorying Information Technology Systems: Supporting the "Paradigm of Change"

Mordechai Ben-Menachem, Garry S. Marliss

IEEE Software, Vol. 21, No. 5, pp. 34-43 , September/October 2004

Keywords: enterprise asset classes, software economics, asset management, IT portfolio managemen

ITシステムは組織に浸透しており、ほとんどすべての業務を支援している。IT それ自体の管理以外は。 ソフトウェア構成管理システムは(ある)管理に関しての支援をいくらか提供するが、分散された企業全体を扱ったり管理情報資源としての役割を果したりするようには設計されていない。 ソフトウェア資源は組織資産の主要な構成要素であるが、棚卸しされるまではそのように扱われることはない。 ソフトウェアの棚卸しは、技術的なプロセスやビジネスプロセスの絶え間ない変化を管理するという課題を扱うために開発された,統合された技術の集合のひとつである。 これらの技術は変化のパラダイムと呼ばれる進化型ビジネスパラダイムの側面である。 エンタープライズITの棚卸しを作成することは膨大な量の情報が要求される複雑な仕事であるが、そのような投資により相当な収益を生み出すことができる。

HT


技術産業におけるネットワークの影響と社会的ジレンマ
Network Effects and Social Dilemmas in Technology Industries

Glenn J. Browne, Nirup M. Menon

IEEE Software, Vol. 21, No. 5, pp. 44-50 , September/October 2004

Keywords: network effects, social dilemmas, standards, monopolies

この論文では技術産業におけるネットワークの効果について記述する。 特に、ネットワークの効果が“社会的なジレンマ”を導きうることを示す。それは、消費者の行動がその消費者自身や,長期的に見れば社会全体に対して長期間に渡り深刻なマイナスの結果を与え得るということである。 我々は、市場における全ての企業や消費者が得ることができる社会の余剰を説明するためにソーシャルプランナーの市場の視点を用いた。 我々は経済学、社会科学、生物学の理論を用いて、社会の余剰を増加させるために技術市場が先を見越した計測を要求することについて議論する。 我々は、短期間および長期間でのネットワークの効果をコストと利益を述べながら議論する。 そして、社会的なジレンマ問題への潜在的な解決法を提案し、政府や組織への処方せんを示し締めくくる。

HT


ブラックボックスを越えて:ソフトウェアのアウトソーシングにおける知識の重複
Beyond the Black Box: Knowledge Overlaps in Software Outsourcing

Amrit Tiwana

IEEE Software, Vol. 21, No. 5, pp. 51-58 , September/October 2004

Keywords: outsourcing, congruence framework, knowledge management, software development, software project risk, black-box development

ソフトウェア開発のアウトソーシングのよく知られたブラックボックスモデルは概して効果的である。 この手法はお互いの組織が相手のドメインを深く理解することなく、ベンダーがクライアント組織のビジネス課題を解決できることを前提にしている。 この記事は209の世界的なプロジェクトを実地調査した報告であり、ブラックボックス手法の限界とともにそれらの限界に対して取り得る解決方法を示したものである。 この調査による大きな発見は、ブラックボックス手法が定型的なプロジェクトに対してはほとんどの場合で効果的だが、新規性のあるプロジェクトではうまくいかないということだ。 新規プロジェクトではその新規性のタイプに応じた、ブラックボックスモデルからの慎重な逸脱が求められる。 概念的には、新規の開発プロセスを含むプロジェクトがクライアント側に深い技術的な専門知識を要求する一方で、新規プロジェクトではベンダーがクライアントの業務を深く理解することが求められる。 この記事では能力の成熟度や熱心なアーキテクチャ設計努力、開発を協調させるツールがもたらす効果に対する見識を示す。 この調査結果をソフトウェア開発の実践へ適用するために,知識を調和させるフレームワークを提案する.

HT


自動的に再利用可能なUMLのシーケンス図を発見する
Finding Reusable UML Sequence Diagrams Automatically

William N. Robinson, Han G. Woo

IEEE Software, Vol. 21, No. 5, pp. 60-67 , September/October 2004

Keywords: software, software engineering, analysis, design, CASE (computer-aided software engineering), reuse models, UML (unified modeling language)

ソフトウェアアナリストは多くの成果物を作る。そして最近までそれらは再利用しにくいものであった. REUSERはアナリストが自動的に再利用のための関連する成果物を取り出せるようできるCASE(computer-aided software engineering)ツールである。 REUSERへの評価が、そのUML成果物を再利用するための手法が効果的であることを示唆している。 さらに、その基礎をなすグラフベースの概念クラスタリング技術が、構造をもったドメインにおいてたびたび活躍してきた。 この記事は、アナリストがUMLのシーケンス図を再利用することに対してこのツールが行う支援の有効性に関する著者の報告である。

HT


じれったい創造性:あなたの要求がどのようなものか想像せよ
Provoking Creativity: Imagine What Your Requirements Could Be Like

Neil Maiden, Alexis Gizikis, Suzanne Robertson

IEEE Software, Vol. 21, No. 5, pp. 68-75 , September/October 2004

Keywords: requirements engineering, creativity workshops

要求工学の研究は、その誘出、分析、管理に焦点を当てているため、要求の開発や考案への支援はほとんど提供していない。 この記事は航空管制システムへの要求に対して、創造的な考え方を促進するために革新的なテクニックを利用したことの報告である。 この記事では、3つの創造性向上ワークショップの結果と,創造性向上ワークショップを統合して構造化された要求プロセスを構築する教訓を述べる。

HT


ペアプログラミングの実地調査:生産性への影響と推測される結果
A Field Study of Developer Pairs: Productivity Impacts and Implications

Allen Parrish, Randy Smith, David Hale, Joanne Hale

IEEE Software, Vol. 21, No. 5, pp. 76-79 , September/October 2004

Keywords: software engineering productivity, programming teams, extreme programming, agile software processes

研究者はペアのプログラマと独立したプログラマの生産性に関して、多様な、実に本質的に異なった発見をしてきた。 著者らはアジャイルソフトウェア方法論と関連するロール・ベースの協調手続きは、並行作業のペアプログラミングに付随する重大な生産性の損失を克服すると結論を出す。

HT


モデル駆動型開発のためのテスト駆動型モデリング
Test-Driven Modeling for Model-Driven Development

Yuefeng Zhang

IEEE Software, Vol. 21, No. 5, pp. 80-86 , September/October 2004

Keywords: model-driven development, extreme programming, test-driven development, automatic code generation

エクストリームプログラミング(XP)はコード中心の、軽量なソフトウェア開発プロセスである。 XPではテストがキーポイントとなっている。なぜなら、開発者がコードを書く前にテストケースを記述し、テストがコードの完了を決定するからである。 テスト駆動型モデリング(TDM)と呼ばれる新しいソフトウェア開発プロセスは、XPのテスト駆動型のパラダイムをモデル駆動型開発環境に適用したものである。 TDMはシミュレーションによる自動テストや動くソフトウェアシステムアーキテクチャの文書として実行可能なモデルを使用することを伴う。 これまでの計画駆動型の方法と比べると、TDMはメッセージシーケンス図やモデリングの図を再利用するため、大幅に時間を削減できる。 TDMが,コードの欠陥の数において高い品質が要求される巨大プロジェクトの開発に,有効に適用できることを実地の結果が示している。

HT


ソフトウェア製品の品質を測る:ISO/IEC 9126の調査
Measuring Software Product Quality: A Survey of ISO/IEC 9126

Ho-Won Jung, Seung-Gweon Kim, Chang-Shin Chung

IEEE Software, Vol. 21, No. 5, pp. 88-92 , September/October 2004

Keywords: ISO/IEC 9126, software quality model standards

国際標準であるISO/IEC 9126はソフトウェア製品の品質モデルを定義している。 そのモデルではソフトウェア製品の属性を6つの特性に分類している。また、それらはさらに27の副特性に細分されている。 ユーザ調査に基づく本探求調査は、ISO/IEC 9126の分類が正しく信頼できるかを、パッケージ化されたソフトウェア製品の品質を審査してもらいユーザの満足度を評価することで実験的に調査する。 その結果は製品の品質属性に対する我々の理解を明確にすることの助けとなり、標準を改訂するための手引きとなる。

HT


要件とビジネスケース
Requirements and the Business Case

Suzanne Robertson

IEEE Software, Vol. 21, No. 5, pp. 93-95 , September/October 2004

Keywords: business case, software engineering

我々は正しい要件を発見することの必要性について耳にすることが多い。 しかし、どの要件が正しかはどうすればわかるのだろうか。 プロジェクトのコストと利益に対する定量的な見込みに加えて、そのプロジェクトを行う明快な理由が必要である。 我々はしばしばこの知識の集積をビジネスケースと呼ぶ。

HT


想像力
Imaginate

Andy Hunt, Dave Thomas

IEEE Software, Vol. 21, No. 5, pp. 96-97 , September/October 2004

Keywords: software construction, agile development, application development

我々は、事業としてひとつの統一されたパッケージで世界中の全ての問題を解決できるようなすばらしいフレームワークを作りたいと考えている。 そのフレームワークを手にすれば、要求に応じてカスタマイズされる実績がありデバッグされたたくさんのオブジェクトのプロトタイプを組み合わせることができるため、 ただユーザと席を共にするだけでセキュリティ、ナビゲーション、ユーザのスクリプト言語などを備えた頑丈で堅牢なアプリケーションを手早く書くことが現実的にできるようになる。 しかし、我々の全てのリソースをもってしても、未だにそのようなことは上手く成し遂げられていない。 大抵、急いでかき集めて作られたアプリケーションは長い目で見ると法外な金額を要求され、メンテナンス性や拡張性が全くない流砂のようなVisual Basic、Foxpro、Perlコードの山を後に残す。 この記事では、どのようにすれば必要とされる限り長持ちし価値を生む、シンプルで理解、維持、強化、拡張するのが容易なソフトウェアを作ることが可能であると主張できるかを探求する。

HT


エンド・ツー・エンド欠陥モデリング
End-to-End Defect Modeling

Jean-Jacques Gras

IEEE Software, Vol. 21, No. 5, pp. 98-100 , September/October 2004

Keywords: cause-effect modeling

ソフトウェアの品質を促進するための因果モデルの使用は、あなたの組織をより高い成熟レベルに押し上げることができる。

HT


ニュースから
In the News

Laurianne McLaughlin, Benjamin Alfonsi

IEEE Software, Vol. 21, No. 5, pp. 101-105 , September/October 2004

ヨーロッパ連合がソフトウェア特許の新しい規則に苦労している。 (Laurianne McLaughlin)

ヨーロッパ連合諸国における特許プロセスのさらなる標準化促進のために提案された法律が、ソフトウェアやビジネスの方法論に関しての修正の議論の火種となってきた。

短い記事:

eBayソフトウェア開発者の押し売り(Benjamin Alfonsi)

NSFのリーダであるFrank Anger死去

HT


書棚
Bookshelf

Terry Bollinger, Mike Barker, Philipp K. Janert

IEEE Software, Vol. 21, No. 5, pp. 106-109 , September/October 2004

レビュー:

“Succeeding with Open Source” 『オープンソースで成功する』

“Quality Software Management, Volume 4: Anticipating Change” 『ソフトウェアマネジメントの品質,4巻:変化の予想』

“Waltzing with Bears: Managing Risk on Software Projects” 『熊とワルツを:ソフトウェアプロジェクトのリスク管理』

HT


ソフトウェア工学用語集:ソフトウェア設計,パート1
Software Engineering Glossary: Software Design, Part I

IEEE Software, Vol. 21, No. 5, pp. 110 , September/October 2004

Keywords: software engineering schedule pressure

何人かのソフトウェアの専門家が言っているであろう事に反して、スケジュールのプレッシャーはソフトウェア技術者にとってよいものではない。

HT

IEEE Software (IEEE) Vol.21, No.6


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


[インデックス] [前の年] [次の年]