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


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

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


ソフトウェア従事者へのマーケティング技術
Marketing Technology to Software Practitioners

Shari Lawrence Pfleeger and Winifred Menezes

IEEE Software, Vol. 17, No. 1, January/February 2000

Keywords: marketing technology, technology transfer, technology selection decision

我々は, 効果的な技術の伝達に関して, ビジネスコミュニティより 多くのことを学べる. 特に, 異なるタイプの(技術の)採用者の関心 事を理解することで,誰かに納得して革新的な技術を試させるのに 必要な異なる種類の証拠を知ることができる.

同時に法律コミュニティからは,ある革新が現在のやり方に対する 改善であるという説得力のある論拠を組み立てるのに,どのような 種類の証拠が必要とされるかに関する助言を得ることができる.本 稿は,我々が技術選択の決定をなぜ,そしてどのように行うのかに ついて調べ,またこれらの決定を支える証拠がどのように新しい技 術の採用を助けるか,あるいは妨げるのかについて考察する.


エンジニアは作らない
Engineers Don't Build

Terri Maginnis

IEEE Software, Vol. 17, No. 1, January/February 2000

Keywords: construction, software development methodology, master-builder approach, architect, engineer, builder, inspector

我々のほとんど誰も,けしてソフトウェア開発方法論をもって建築 プロジェクトに取り組むことはない.しかし,建築プロジェクトは ソフトウェア開発プロジェクトよりもはるかに高い成功率を示す. Maginnisは,多くのソフトウェア開発プロジェクトにおいてとられ る,『棟梁(master-builder)』手法について明らかにする.その手 法において,開発者はアーキテクト(architect; 建築家),エンジ ニア(engineer; 技師),ビルダ(builder; 施工者),インスペクタ (inspector; 検査官)の役割を担う.ほとんどの大規模建築プロジェ クトは,およそ100年も前にこの手法をやめている.なぜ我々は大 規模ソフトウェアプロジェクトに対してこの手法を用いるのか? エンジニアがシステム(建物)を設計し,プログラマ(ビルダ)が実装 する.この手法は,品質,納期,予算の点で,より大きな成功率を もたらす.


ソフトウェア工学:コミュニティと文化
Software Engineering: Community and Culture

Helen Sharp, Hugh Robinson, and Mark Woodman

IEEE Software, Vol. 17, No. 1, January/February 2000

Keywords: software engineering, community, paradigm, software quality management system

社会科学からのアイデアと技法により, ソフトウェア工学分野の定 理と実践を改善することができる.この他花受粉 (cross-pollination)のしてきた貢献を説明するために,著者らは パラダイムとソフトウェア品質管理システムの性質に焦点を当てる. 彼らの研究は,ソフトウェア技術者らがあまりにもしばしば証拠を 求めて好んで議論するにも関わらず,新しい技術的アイデアが受け 入れられるようになる方法におけるコミュニティの重要性と, 局所 的な指導者(local guru)に与えられる形式的な組織構造を超越した 卓越性を強調している.


ソフトウェア生産性向上手法とリスクを明確にする:建築産業のケーススタディ
Identifying Software Productivity Improvement Approaches and Risks: Construction Industry Case Study

Peter Hantos and Mario Gisbert

IEEE Software, Vol. 17, No. 1, January/February 2000

Keywords: software productivity, global economy, software process improvement

世界経済(global economy)の現実により,たとえ現在ソフトウェア 分野が合意の得られたプロセスと品質メトリクスの標準を欠いてい るとしても,米国の製造業はより効果的にソフトウェア開発を管理 する方法を見出すことを強いられている.ソフトウェアの研究開発 における改善をうながすには,学際的な他花受粉 (cross-pollination)手法が個人とグループの編成の中で多くの利 益をもたらすことができる.HantosとGisbertは,建築産業の有名 な教育ビデオを用いて,ソフトウェアプロセス改善に対する,文化 的な,制度上の,そして実装上の障壁を打破する方法を明らかにす る.


会計専門職からのソフトウェア実践のためのモデル
A Model for Software Practices from the Accounting Profession

Bryan Kocher

IEEE Software, Vol. 17, No. 1, January/February 2000

Keywords: software practice, Y2K, information system, standard

著者ははじめに,2000年問題と1929年の米国株式市場の恐慌を比較 する.株式市場恐慌に由来する米国会計専門職のための規則とちょ うど同じように,著者は情報システム標準委員会(Information Systems Standards Board)を求めており,そういった組織があれば 2000年問題を避けることができただろう,そして将来もそのような 大失敗が起きることを防げるだろうと主張する.


モジュール型ソフトウェアプロセスミニ評価手法
A Modular Software Process Mini-Assessment Method

Karl E. Wiegers and Doris C. Sturzenberger

IEEE Software, Vol. 17, No. 1, January/February 2000

Keywords: software process assessment, CMM, assessment component

本稿は,ある組織がそのプロセスに関するフィードバックを望んで はいるが,『公式』のCMM評価を行うのに骨の折れる3週間を奉げる ことはできないという,ソフトウェアプロセス評価における共通の 問題に対処するための1つの手法について述べている.このミニ評 価手法においては,調査を特定の関心事に集中させ,労力を組織に 適したレベルに合わせるために,個々の評価構成要素が選択される.


ソフトウェアのテストって何? なぜそんなに難しいの?
What Is Software Testing? And Why Is It So Hard?

James A. Whittaker

IEEE Software, Vol. 17, No. 1, January/February 2000

Keywords: software testing

著者は,今日のソフトウェア製品のテストがなぜそんなに難しいの かということについていくらか解明し,全てのテスタがきっと完全 に適用することができるであろういくつかの堅実な手法を明らかに する.有能なテスタは,基礎的なテスト技法という貴重なツールキッ トを持っており,その動作環境において製品がどのように用いられ るかを理解し,とらえにくいバグが製品のどこに潜んでいるかを嗅 ぎつける鼻と,パッとそれらをあらわにする一連のトリックを持っ ている.ここに述べられる手法によって,テスタがあるソフトウェ アシステムのテストを終了したと言う時,本当は何を意味している のかという質問に対して,分別をもって答えることができるだろう.


ソフトウェア開発の生産性をベンチマークする
Benchmarking Software-Development Productivity

Katrina D. Maxwell and Pekka Forselius

IEEE Software, Vol. 17, No. 1, January/February 2000

Keywords: benchmarking, software development productivity

本稿は,26のフィンランド企業における206のビジネスソフトウェ アプロジェクトのデータが格納されたある独特なデータベースを使っ て, 生産性の変動の統計分析について考察する.著者らは,銀行, 保険,製造,卸売り/小売り,そして行政機関の領域における生産 性を示す要因に関して,相違点を調べている.著者らは,新しいプ ロジェクトを始める際に予想される生産性を見積もるのにも,それ ぞれのビジネス領域に対する完了したプロジェクトをベンチマーク するのにも役に立つ,生産性ベンチマーク方程式を提案する.

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


オブジェクト指向世界のCobol:学習的な展望
Cobol in an Object-Oriented World: A Learning Perspective

Bill C. Hardgrave and E. Reed Doke

IEEE Software, Vol. 17, No. 2, March/April 2000

最近のインターネット、Java,オブジェクト指向のトレンドは、 Cobolの占有領域を脅かしているが、Cobol言語とそれを使って保守 のみならず開発をするプログラマは、特にオブジェクト指向Cobol が公式に標準となると、産業においてさらに必要とされ続けるであ ろう。その結果、Cobolトレーニングは優先事項としてとどまる。 Cobolプログラマは、彼らの持つ知識を活用することで、スムーズ にオブジェクト指向開発やJavaプログラミングに移行することがで きる。


Cobolの真の創造者
The Real Creators of Cobol

Jean E. Sammet

IEEE Software, Vol. 17, No. 2, March/April 2000

よくある神話的通念に反して、Cobolは、1人によってではなくある 委員会によって1959年に最初に作成された。この記事は、Cobol言 語を開発した委員会の創設とミッション、そしてCobolの初期の開 発における幾つかの主な入力と反響について概説し、そして実際に 関わった人々についても含める。この記事の内容は、著者が所有す る1959年の委員会活動の文書に基づいている。


継続的なCobol教育の事例
The Case for Continued Cobol Education

Donald Carr and Ronald J. Kizior

IEEE Software, Vol. 17, No. 2, March/April 2000

Cobolの将来に対するIS(情報システム)管理者の見方と学識者の見 方を調べると、このサーベイで、95%の学識者の回答と90%のIS管 理者は、IS科目はCobol教育を提供しつづけることが必要であると 投票したことが判った。また、90%近くのIS管理者は、大学での Cobol教育は、Cobolのオブジェクト指向とWebベースの機能の両方 をカバーするべきであると指摘している。


レガシー統合:変化の展望
Legacy Integration: Changing Perspectives

Frank P. Coyle

IEEE Software, Vol. 17, No. 2, March/April 2000

レガシーという用語は、Webの広範囲な成功と既存システムを早く インターネットの中に取り込むという要求とに伴い、新たな意味合 いを持ちつつある。Cobolプログラムやデータは、内部連結やコー ドとデータ両方のための内部連結や統合の選択肢を与える新たな可 能性として見られつつある。


Y2Kの戦略的な恩恵
Some Strategic Y2K Blessings

Leon A. Kappelman

IEEE Software, Vol. 17, No. 2, March/April 2000

Y2Kは、多くの人々に事業成功(enterprise success)におけるシス テムやソフトウエアの重要性を示し、ソフトウエアのプロフェッショ ナルたちに価値ある教訓を与えた。著者は、IT産業はY2Kからそれ 自体を理解することや、そのソフトウエアシステムをアップグレー ドしたり再設計したりその実践から得られた知識を調べることが必 要であると説いている。


2000年代のCobol
Cobol for the Next Millennium

Don Schricker

IEEE Software, Vol. 17, No. 2, March/April 2000

新たなCobol標準、Cobol2002は約18ヶ月で完了すると見られている。 Cobol2002は、Cobolの一次クラスデータのハンドリング機能上で構 築され、オブジェクト指向的特徴、環境上の改良、多くの他の最新 の構成概念(constructs)を言語に導入している。こうした改善の結 果、Cobolはビジネス用言語と、多様なプログラミングの課題を取 り扱う能力のある汎用言語との両方兼ね備えたプログラミング言語 としての位置が得られる。


生産性を向上させるOPENフレームワーク
The OPEN Framework for Enhancing Productivity

Brian Henderson-Sellers

IEEE Software, Vol. 17, No. 2, March/April 2000

ビジネスに特化した開発プロセスの利用は、Cobolプログラムの生 産や保守の便宜を大きく向上させることができる。著者たちは、 OPEN(object-oriented process, environment, and notation)プロ セスフレームワークの概要を示す。それは、Cobol言語を用いた実 装を行うビジネス環境において、オブジェクト指向開発かつコンポー ネント指向開発を行うために今日最も適切なプロセスである。その 基礎となるメタモデルとフレームワークによって、OPENは開発と保 守の両方で価値が与えられる。


Cobolのツール:概要と用語
Cobol Tools: Overview and Taxonomy

Edmund C. Arranga, Thane Hubbell, Alden C. Lorents, Steve Shiflett, and Jon Wessler

IEEE Software, Vol. 17, No. 2, March/April 2000

ポストY2Kの最も大きな挑戦の1つに、レガシーリニューアルであ る。しかし一体いくつのツールが使えるのかを知らない。4つのツー ルをここではスポットをあて、新規なGUIのフロントエンドからコ ンポーネントの作成までの、レガシーリニューアルの選択肢の範囲 を示す。ツールの分類リストには、さまざまなツールを100以上カ バーして、そのURLと共に示す。


ソフトウェアテスタのためのキャリアパスを説き明かす
Clearing a Career Path for Software Testers

Elaine J. Weyuker, Thomas J. Ostrand, JoAnne Brophy, and Rathna Prasad

IEEE Software, Vol. 17, No. 2, March/April 2000

信頼性があり頼りがいのあるソフトウエアシステムを成功裏に作成 するためには、効率のよいテストが必要不可欠となる。しかし、あ る個人が能力の高いソフトウエアテスタになる適任者かあるいはそ の潜在能力があるかを決定する形式的な判定基準はほとんどない。 著者たちは、AT&Tにおいて、ソフトウエアテスタが、まず訓練 を受け、認定されたソフトウエアテスト技術者になり、さらにソフ トウエアテスティング専門家に至ることのできるキャリアパスを定 義したプログラムを開発した。


COTSとはどういう意味か?結局、1つの便利な答え。
What Do You Mean by COTS? Finally, a Useful Answer

David Carney and Fred Long

IEEE Software, Vol. 17, No. 2, March/April 2000

COTS(Component of the Shelf:すぐに使えるコンポーネント)とい う頭字語の使用は便利であるが、混乱を招くこともありうる。著者 たちは、コンポーネント間の通信を明確にし、特定のシステムにお いてコンポーネントをどのように使えばいいのかという理解を向上 させ、さらに評価戦略を解明するメカニズムを提案している。その 手法は、関心(interest)の異なる軸に沿って属性を分離し、関心の 異なる軸や関心の多重点(multiple points)を伴うグラフィカル空 間の中に各コンポーネントを布置する。今日より重要性を増してい るコンポーネントベースのシステムを十分に理解することが求めら れているとすれば、こうしたメカニズムの価値は、それを使うこと で増える労力に勝るかもしれない。

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


軽量な形式手法を用いて音声コミュニケーションの要求を検証する
Validating Voice Communication Requirements Using Lightweight Formal Methods

Johann Hoerl and Bernhard K. Aichernig

IEEE Software, Vol. 17, No. 3, May/June 2000

軽量なアプローチによって形式開発手法の技術移行が容易になると いう立場を支持するために, 安全性が重要となる航空管制のための 音声コミュニケーションシステムを, VDM++を使って定義した著者 らの経験について報告する.

[訳注] VDM++: IFAD社が開発したオブジェクト指向の形式言語. VDM = Vienna Development Method


要求の交渉に異なるコミュニケーション媒体を使う
Using Different Communication Media in Requirements Negotiation

Daniela E. Herlea Damian, Armin Eberlein, Mildred L.G. Shaw, and Brian R. Gaines

IEEE Software, Vol. 17, No. 3, May/June 2000

面と向かって接することでグループの能力が向上するという信念に 反して, 著者らの研究は, 要求の交渉において, 面と向かってミー ティングするグループの仕事が, テレビ会議とコンピュータ補助を 使うグループと変わりないことを示している.


要求と仕様のための参照モデル
A Reference Model for Requirements and Specifications

Carl A. Gunter, Elsa L. Gunter, Michael Jackson, and Pamela Zave

IEEE Software, Vol. 17, No. 3, May/June 2000

著者らは, 形式手法をユーザ要求の構築とシステム機能仕様への落 とし込みに適用するための参照モデルを定義する. 彼らの手法は, システムとその動作する環境の間のインターフェイスを定義する共 有の現象と, このインターフェイスの部品がどのように制御される かに焦点を当てる.


統計的プロセス管理の実務への適用
Practical Applications of Statistical Process Control

Edward F. Weller

IEEE Software, Vol. 17, No. 3, May/June 2000

定量的手法と統計的プロセス管理をソフトウェア開発プロジェクト に適用することで, プラスのコスト恩恵を受けることができる. 著 者は, テストの定量分析と, テストにおいて製品品質を評価し, ソ フトウェアのメジャーリリースに向けて出荷後の製品品質を予測す るためのテストデータを用いた.


GQM計測プロセスのための自動化サポートの提供
Providing Automated Support for the GQM Measurement Process

Luigi Lavazza

IEEE Software, Vol. 17, No. 3, May/June 2000

計測はソフトウェア開発を管理し改善するための重要な要素である. 本稿は, Goal Question Metrics(GQM)計測プロセスの最も高価なフェ イズの自動化について説明する. 特に著者は, 計測の定義, 収集, 解析, フィードバックのためのツール, そしてこのツールと構成管 理システムやメトリクスツールを連携させるテクニックについて述 べている. これらのテクニックは, ある産業の場面において実施さ れた計測プログラムにおいて使われた.


航空管制を再設計する:ソフトウェア設計の練習問題
Redesigning Air Traffic Control: An Exercise in Software Design

Daniel Jackson and John Chapin

IEEE Software, Vol. 17, No. 3, May/June 2000

1998年の秋, 著者らは, NASAにより開発され, 現在アメリカ合衆国 のいくつかの空港で採用されている航空管制システム CTAS の1コ ンポーネントを再設計した. このケーススタディは, 基本的なソフ トウェア工学のテクニックによって, いかに複雑なシステムを劇的 に単純化することができるかを示している. 著者らは, 航空管制シ ステムを様々なツールを用いてリバースエンジニアリングし, より 小さくより単純でそしてより柔軟なものへと再設計することから学 んだ教訓について述べる.


ソフトウェアプロセス:死ぬのは奴らだ
Software Processes: Live and Let Die

Allan Baktoft Jakobsen

IEEE Software, Vol. 17, No. 3, May/June 2000

ソフトウェアビジネスは骨が折れる. それには正しい製品だけでな く, 正しい開発プロセスも必要である. 本稿は, ある破滅的ソフト ウェア製品のリエンジニアリングと, 開発者が使った2つの異なる リエンジニアリングプロセスについて述べる. 著者は, 片方のプロ セスが失敗し他方が成功した理由について説明し, ソフトウェア開 発においては人とプロセスが調和しなくてはならないと主張する.


計算機科学クラスのためのフリーソフトウェア
Libre Software for Computer Science Classes

Jesus M. Gonzalez-Barahona, Pedro de-las-Heras-Quiros, JoseCenteno-Gonzalez, Vicente Matellan-Olivera, and Francisco J. Ballesteros

IEEE Software, Vol. 17, No. 3, May/June 2000

著者らは, 386BSDを使ってスペインカルロス3世大学の計算機科学 クラスを教えた初期の経験について述べ, そこから学んだ教訓につ いて議論する. 彼らはまた, 実際の計算機科学教育にフリーソフト ウェアを使った理由について論ずる.


言語学の道具をオブジェクト指向分析に使う方法
How to Use Linguistic Instruments for Object-Oriented Analysis

Natalia Juristo, Ana Maria Moreno, and Marta Lopez

IEEE Software, Vol. 17, No. 3, May/June 2000

オブジェクト指向手法をソフトウェア開発に適用する制限の1つは, オブジェクト指向分析のプロセスが未成熟であることだ. 本稿は, このプロセスの過程で適用される, 非形式的な仕様からの言語情報 の使用に基づいたアプローチを提案する. 提案された手法はこの情 報を意味的にそして文法的に分析するのを助け, 準形式的な手続き を用いて, そういった分析からオブジェクト指向システムのコンポー ネントを抽出する.


ビジネスに直結した保守プロジェクトの人員配置方法
How to Staff Business-Critical Maintenance Projects

Ramkumar Ramaswamy

IEEE Software, Vol. 17, No. 3, May/June 2000

保守プロジェクトのチーム規模は, 保守要求の発生する頻度と, そ れぞれの要求に対して迅速に対応することの重要性に依存する. 著 者は, この考えに基づいた, 保守プロジェクトの人員配置のための 5段階の手法を示す. その手法は, 使いやすい検索テーブルとして 提供される待ち行列モデルからの結果を用いる. そしてこの結果は 経験的かつ質的な入力を使って洗練され, 有用で実際的な人員配置 の見積もりをもたらす. 著者は, ある実際のプロジェクトからのデー タを用いて手法を説明する.

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


ペアプログラミングの立場を強める
Strengthening the Case for Pair Programming

Laurie Williams, Robert R. Kessler, Ward Cunningham, and Ron Jeffries

IEEE Software, Vol. 17, No. 4, July/August 2000

Keywords: pair programming, collaborative programming, Extreme Programming (XP), programming quality, programming productivity

ソフトウエア産業は、ペアプログラミング-二人のプログラマは協 力して1つのコンピュータで1つの問題を作業するということを、 何年も実践したきた。しかし、これを試したことのない人は、資源 の無駄であるとしてこの考えを多くの場合拒絶する。著者は、ペア プログラミングは、より短い時間で良いソフトウエア製品を生み出 し、また仕事に満足し自信を持ったプログラマを生むということを 示す。こうしたペアプログラミングを支持する証拠は、プロフェッ ショナルなプログラマから、そして大学生で行なった実験から得ら れる。


小チームに対するスクラムソフトウエア開発プロセス
The Scrum Software Development Process for Small Teams

Linda Rising and Norman S. Janoff

IEEE Software, Vol. 17, No. 4, July/August 2000

Keywords: software development process, incremental software development, project management, risk management, time boxing, postmortems, requirements change, team size, team communication

今日のソフトウエア開発をめぐる環境において、製品開発のライフ サイクル期間中に揺れ動くビジネス要求に合わせるため、要求仕様 はしばしば変更される。このことは、開発チームの頭痛の種となっ ている。著者たちは、この問題に取り組み、AG通信システムからス クラム‐ソフトウエア開発プロセスを実現した彼らの経験を議論す る。スクラム‐ソフトウエア開発プロセスを経験した中で、彼らは 適切なスクラムの変形を定義し適用することで、小さなチームが柔 軟で適応し易くできることを明らかにした。


ソフトウエアのスタートアップにおけるプロセスの役割
The Role of Process in a Software Start-up

Stanley M. Sutton, Jr.

IEEE Software, Vol. 17, No. 4, July/August 2000

Keywords: start-up, process, established companies, organization

この記事では、商業ソフトウエアのスタートアップ(操業開始)にお けるプロセスの役割について議論する。まずスタートアップの特徴 とスタートアップしたばかり企業と確立した企業との間の違いを明 らかにした後、著者は、確立した企業とは異なる理由と方法になる けれども、スタートアップでおいてプロセスに注意を払うべきと結 論付ける。本記事は、スタートアップした企業が、その組織内部で プロセスに取り組み改善することができる方法を提案している。


多様な開発環境に対するCMMプロジェクト計画作成の実践の適用
Applying CMM Project Planning Practices to Diverse Environments

Donna L. Johnson and Judith G. Brodman

IEEE Software, Vol. 17, No. 4, July/August 2000

Keywords: CMM, commercial-off-the-shelf, nontraditional, small organizations

今日多くの組織が、SEI(Software Engineering Institute)のソフ トウエア成熟度モデル(CMM:Capability Maturity Model)を使って、 データベースを開発し、市販製品をインストールし、サービスを提 供し、あるいは保守を行なっている。小規模な組織あるいは、小規 模なプロジェクトからなる組織もまた成熟度モデルを使おうとして いているが、彼らの従来とは異なる開発業務にCMMを適用する難し さを予期している。著者たちはこうした組織が、CMMの実践を教義 (gospel)として扱うのではなく、CMMの趣旨に焦点を当てて彼らの プロジェクト計画作成プロセスをどのように改善するかを示す。


COTSベースのシステムへの新たなプロセスの開発
Developing New Processes for COTS-Based Systems

Lisa Brownsword, Tricia Oberndorf, and Carol A. Sledge

IEEE Software, Vol. 17, No. 4, July/August 2000

Keywords: commercial-off-the-shelf (COTS), commercial products, commercial technology, software process

商用の技術や製品を使ってシステムを開発することは一般的になっ てきている。アプリケーション開発者は、システムの新規開発や保 守に対するダイナミックな原則やプロセスをよりよく理解するよう にならなくてはならない。今日彼らは、COTS(Component On The Shelf)製品が既存のシステム開発プロセスにどのように影響を及ぼ すか、あるいは新たなプロセスが必要なのかについての情報をほと んど持っていない。 Software Engineering Instituteに属する著 者たちは、COTSベースのシステムを開発あるいは保守するための新 しいプロセス要素と変更したプロセス要素を示す。


再利用プロセスの多様性
Diversity in Reuse Processes

Maurizio Morisio, Colin Tully, and Michel Ezran

IEEE Software, Vol. 17, No. 4, July/August 2000

Keywords: software processes, software reuse

著者たちは、計画的再利用(systematic reuse)を達成する、4つの 会社から示されたプロセスを示し、さらにそれらを比較する。これ らの会社は、規模やビジネス領域、開発アプローチが異なっている。 しかし、基本的なプロセスや技術がまったく異なっているにも関わ らず、全て再利用の目標を達成している。この記事では異なるプロ セスで成功させたキーとなる理由を議論する。そこには、マネージ メントが強力に関与したことや、変更に対する問題を明確にし注意 を払ったこと、そして変更を最小限にすることを含まれている。


プロジェクトに合う方法論の選択
Selecting a Project's Methodology

Alistair Cockburn

IEEE Software, Vol. 17, No. 4, July/August 2000

Keywords: cultures, methodology, methods, people, project experiences, software development process, software engineering practices

様々な方法論はそれぞれ必然性があり、何が方法論を構成している のかと、何が方法論の基礎とする原則なのかという疑問から直接生 じる。サイズや構成、特性そして危険性によってもプロジェクトが 異なってくる。プロジェクトに関わる人々は、彼らの経験や規範あ るいは心配事に基づいて、それぞれ偏りを持っている。これらの問 題を統合してプロジェクトを超える最適なものとする。この記事で は、いつより重量級の方法論あるいはより軽量級の方法論を選択す るための原則、方法論の差別化のフレームワーク、そしてこれらの アイデアを使ったプロジェクト経験について報告する。


Tata Consultancy Servicesにおける品質プロセスの進化
The Evolution of Quality Processes at Tata Consultancy Services

Gargi Keeni

IEEE Software, Vol. 17, No. 4, July/August 2000

Keywords: control charts, Malcolm Baldridge National Quality Award, metrics, process spread, Software CMM, statistical process control, U-charts

Tata Consultancy Services社(TCS)は、90年代初期から様々な品質 モデルに対して自社のベンチマーキングを行なってきている。すべ てのTCS開発センターでは1995年以降ISO9001の認証を受けてきた。 インドにある17の開発センター中、7つのセンターはCMMで最高ラン クの5レベルと評価され、1つのセンターは4レベルと評価された。 TCSは1996年にCMMによる自社のベンチマークを開始したが、その品 質主導の基盤は、80年代にさかのぼって築かれた。この記事では、 ここに至った経緯と得られた教訓を述べる。

ISO9000主導は監査プロセスを規定し、組織レベルで品質管理シス テムを設ける手段となる。定量的プロセス管理は、統計的プロセス 管理によるプロセス能力への組織的な見通しを提供する。CMM V1.1 のレベル5の主要プロセス領域は、繰り返し作業の減少することと 新たなプロセスや技術の評価することへのフレームワークを提供す る。


Telcordia Technologie:高成熟度への旅路
Telcordia Technologies:The Journey to High Maturity

Bill Pitterman

IEEE Software, Vol. 17, No. 4, July/August 2000

Keywords: CMM, culture, customer satisfaction

巨大で多面的な会社が、ISO9001への登録とプロセスのCMMレベル5 への格付けの両方を成し遂げながら、品質や顧客満足は結果論とす る文化から、これらの要素が会社の主体であるソフトウエア開発ビ ジネスの背後で突き動かす力となっている文化にどのように変わる のであろうか?Telcordia Technologiesは、5年間にわたってこう した社内制度全体を変化させた。


統計的プロセス管理:スペースシャトル搭載ソフトウエアの開発プロセスの分析
Statistical Process Control:Analyzing a Space Shuttle Onboard Software Process

William A. Florac, Anita D. Carleton, and Julie Barnard

IEEE Software, Vol. 17, No. 4, July/August 2000

Keywords: Statistical process control, cause systems, process thinking, software processes, SEI

より効率的で有効性があるソフトウエアプロセスへの要求が増大し ており、ソフトウエア工学コミュニティに対して、従来行なわれて きたこと以上に計測を重視することを求めている。統計的そしてプ ロセス思考の原則は、ソフトウエア開発に使われるプロセスの一貫 性と能力を決定付けるために統計的プロセス管理手法を使うことを 導く。この記事は、SEI(Software Engineering Institute)と スペー スシャトル搭載ソフトウエアプロジェクト(Space Shuttle Onboard Software Project)との技術的な共同作業に基づくものである。統 計的プロセス管理を使いプロセスの挙動を分析することに関連する 分析的な要因について、これらの要因の役割を説明する手段である インスペクションプロセスを使って議論する。

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


悪意のあるコードを攻撃する:Infosec Research Council への報告
Attacking Malicious Code: A Report to the Infosec Research Council

Gary McGraw and Greg Morrisett

IEEE Software, Vol. 17, No. 5, September/October 2000

加速する相互接続性, 複雑さ, 拡張性の傾向は, 悪意のあるコード によってもたらされるとっくに深刻になっている驚異を悪化させて いる. 悪意のあるコードと戦うために, 著者らは, ソフトウェアの 振る舞いに関するしっかりとしたポリシーを作ることと, 技術的な 手段を通してそのポリシーを実施することを強く訴える.


あなた自身を守る:侵入検知システムの役割
Defending Yourself: The Role of Intrusion Detection Systems

John McHugh, Alan Christie, and Julia Allen

IEEE Software, Vol. 17, No. 5, September/October 2000

侵入検知システム(IDS)は, コンピュータシステムとネットワーク を悪用から守るための防御対策の重要なコンポーネントである. 本 稿は, 組織の全体的な防御姿勢における IDS の役割について考察 し, IDS の配置, 運用, 保守に関するガイドラインを示す.


セキュリティドメイン:大規模システムにおける要所管理
Security Domains: Key Management in Large-Scale Systems

John R. Michener and Tolga Acar

IEEE Software, Vol. 17, No. 5, September/October 2000

大規模システムにおいて, より上位の構造の中で要所を分割するこ とが必要になってくる. これらの構造をセキュリティドメインとし て確立し管理するには, ローカルサービスを安全に提供するための 基盤構造が必要である.


アプリケーションに特化した実行時のセキュリティホールの除去
Remediation of Application-Specific Security Vulnerabilities at Runtime

Thomas F. Bowen and Mark E. Segal

IEEE Software, Vol. 17, No. 5, September/October 2000

Telcordia Technologies と Stony Brook のニューヨーク州立大学 の研究者達は, 素早い開発と実時間防御の展開によって, アプリケー ションのセキュリティホールにつけこまれるのを防ぐための新しい 能力を, コンピュータ利用者に提供するアプローチについて研究し ている. 彼らの解決策は, アプリケーションの要求するシステムコー ルを横取りすることによるアプリケーションの振る舞いの監視と変 更を含んでいる.


Java コードを静的に走査する:セキュリティホールを見つける
Statically Scanning Java Code: Finding Security Vulnerabilities

John Viega, Tom Mutdosch, Gary McGraw, and Edward W. Felten

IEEE Software, Vol. 17, No. 5, September/October 2000

開発者も利用者もアプリケーションのセキュリティホールに関して ある程度の保証を要求する. 著者らは, プログラマが自動的に既存 のセキュリティに関する知識を利用できるようなツールのプロトタ イプ Jslint を設計した.


小さなソフトウェア開発組織における即興的手法
Improvisation in Small Software Organizations

Tore Dyba

IEEE Software, Vol. 17, No. 5, September/October 2000

ソフトウェア開発およびソフトウェアプロセス改善の従来のやり方 は, 環境が予測可能であることを仮定した理論に基づいている. し かし, ほとんどの小さなソフトウェア開発組織にとって, 環境は絶 えず変わっていてしばしば予測できないものである. 著者は, 即興的手法 と小さな会社におけるその役割について探究する.


中小規模の会社において生産ラインの概念を適用する
Applying Product Line Concepts in Small and Medium-Sized Companies

Peter Knauber, Dirk Muthig, Klaus Schmid, and Tanya Widen

IEEE Software, Vol. 17, No. 5, September/October 2000

中小規模の企業は厳しい制約のもとで仕事をしている. 彼らは顧客 の要求に対してとても柔軟にそして素早く反応する必要があり, し かるに長期的計画に対する可能性を制限している. 著者らは, ある 特定の公的資金によるプロジェクトにおいて, 6つの異なるドメイ ンを扱っている6つの中小企業への, Fraunhofer IESE(Institute for Experimental Software Engineering) で開発した生産ライン ソフトウェア工学(Product Line Software Engineering)手法の適 用を開始した. 本稿は, 24ヶ月間のプロジェクトの仕事から得られ た最初の体験と教訓について述べている. また各社における最初の 結果も含む.


小規模プロジェクト向けソフトウェア開発プロセス
A Software Development Process for Small Projects

Melissa L. Russ and John D. McGregor

IEEE Software, Vol. 17, No. 5, September/October 2000

著者らの開発プロセスは, 反復的インクリメンタルプロセスモデル の一部と, それぞれのプロセスフェイズにおける品質を評価する品 質保証プロセス, およびプロセス改善を手引きするためのデータ収 集を行う計測プロセスを統合する. そのプロセスの目的は, 小さな プロジェクトに大きなオーバーヘッドを強いることなく, 今日の市 場で要求される高い品質と時期を得た結果を生み出すことである.


Web を使ったインクリメンタルな再文書化
Incremental Redocumentation Using the Web

Vaclav Rajlich

IEEE Software, Vol. 17, No. 5, September/October 2000

非常にしばしば, ある企業が他人のソフトウェアを引き継いだもの の, 悲しいことに文書が足りないことにただ気づくばかりとなって しまう. この報告は, ある小さなソフトウェア会社が, どのように, Webベースの分割された注釈(Web-based Partitioned Annotations) を使って, 引き継いだあるソフトウェアアプリケーションを, コス トパフォーマンスよく展開させたかについて述べている.


テストを減らす時
When to Test Less

Tim Menzies and Bojan Cukic

IEEE Software, Vol. 17, No. 5, September/October 2000

著者らは, 多くの小規模プロジェクトにとって, ランダムに選ばれ た少数のテストで十分にソフトウェアを調べることができると主張 する. 彼らは, 限られた資源での素早いテストが, 念入りでお金の かかるテスト体制と同じくらい効果的かどうかを決定するのに, プ ログラムの形状がどのように役立つかを議論する.


Wisdom:小規模ソフトウェア開発会社のためのソフトウェア工学
Wisdom: A Software Engineering Method for Small Software Development Companies

Nuno J. Nunes and Joao F. Cunha

IEEE Software, Vol. 17, No. 5, September/October 2000

Wisdom は, 対話的システムを開発/保守する小さなチームの特定の ニーズに答える新しいソフトウェア工学である. Wisdom はプロセ ス, 表記法, プロジェクトの考え方を定義しているので, コミュニ ケーション, スピード, 柔軟性にてこ入れしている小規模企業にお いてスムーズに適用することができる.

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


履歴データを使ってサイズの見積もりを改善する
Improving Size Estimates Using Historical Data

James Bielak

IEEE Software, Vol. 17, No. 6, November/December 2000

著者は, 完了したC++のプロジェクトについて調査し, 我々が容易 に要求仕様や初期のクラス設計に遡ることができるようなプログラ ミング成果物について考察する.


欠陥見積もりに検査データを使う
Using Inspection Data for Defect Estimation

Stefan Biffl

IEEE Software, Vol. 17, No. 6, November/December 2000

本稿は個人の見積もりから導かれる主観的チーム見積もりモデルを 提案し, 検査データに基づく欠陥見積もりモデルの正確性について 調査する.


Cocomo見積もりモデルを拡張する
Enhancing the Cocomo Estimation Models

Joanne Hale, Allen Parrish, Brandon Dixon, and Randy K. Smith

IEEE Software, Vol. 17, No. 6, November/December 2000

チームでの仕事の割り当ては, プロジェクト全体の成功に対して, 潜在的に大きな影響を与えるようである. 著者らは, 既存の見積も りモデルをチューニングするのに役立つ, 仕事割り当て作業調整要 因(task assignment effort adjustment factor)を提案する. 彼ら は, これらの要因で拡張することによって, Cocomo I, II のいず れにおいても, その予測能力が大きく向上することを示す.


経験的に導かれるソフトウェア活動の推量
Empirically Guided Software Effort Guesstimation

Philip M. Johnson, Carleton A. Moore, Joseph A. Dane, and Robert S. Brewer

IEEE Software, Vol. 17, No. 6, November/December 2000

ハワイ大学における LEAP プロジェクトは, 低コストで経験に基づ いたソフトウェア開発者の向上をサポートするツールと手法につい て研究している. 最近の事例は, 低コストな分析手法により与えら れた場合に, 推量が最も正確な手法となることの証拠を示している.


Web 開発:素早い製品化を要するソフトウェアを見積もる
Web Development: Estimating Quick-to-Market Software

Donald J. Reifer

IEEE Software, Vol. 17, No. 6, November/December 2000

開発者は, Web Objects と呼ばれる新しいメトリクスと, WebMo と 呼ばれる Cocomo II の改作を使って, より正確に, Web ベースの ソフトウェア開発における工数と期間を見積もることができる.


プロセス改善活動の効果を数量化する
Quantifying the Effects on Effort of Process Improvement

Bradford K. Clark

IEEE Software, Vol. 17, No. 6, November/December 2000

組織が多くの改善を並行して実施するとき, 管理者には, その他の 要因に対して, どの程度の改良がプロセスの成熟度によるものなの か決定するすべがない. 本稿は, 161 のプロジェクト例を使って, プロセスの成熟による活動の効果を, 他の効果から分離する.


個人のソフトウェアプロセスに影響する重大な要因
Critical Factors Affecting Personal Software Processes

Xiaoming Zhong, Nazim H. Madhavji, and Khaled El Emam

IEEE Software, Vol. 17, No. 6, November/December 2000

個人のソフトウェアプロセスの品質は, ソフトウェアプロジェクト と組織の成功を決めるのに役立つ. 著者らは, 個人のプロセスに影 響する要因について深く掘り下げる.


パーソナルソフトウェアプロセスに関する体験レポート
An Experience Report on the Personal Software Process

Jagadish Kamatar and Will Hayes

IEEE Software, Vol. 17, No. 6, November/December 2000

本稿は, 数年間にわたり2つの産業プロジェクトのからみでパーソ ナルソフトウェアプロセス(Personal Software Process)を使用し た, 第一著者の体験について報告する. この実体験より得られた説 明では, 教育, 初期の使用, その後の PSP 技法の採用について取 り上げ, 欠陥データの分析と取られた修正活動についても言及する.


PSP を産業に適用する
Applying the PSP in Industry

Maurizio Morisio

IEEE Software, Vol. 17, No. 6, November/December 2000

著者は PSP をある企業に導入した経験について報告している. 導 入後1年が過ぎ, PSP のごく一部は今なお使われている. PSP は, プロセス改善活動を喚起するモデルとして, 何の変更もなく再利用 される既存のプロセスよりも役に立つことが証明された.


うまくいった革新的技術の普及:ソフトウェア開発組織のための手引き
The Successful Diffusion of Innovations: Guidance for Software Development Organizations

Gina C. Green and Alan R. Hevner

IEEE Software, Vol. 17, No. 6, November/December 2000

新しいソフトウェア開発技法をうまく普及して実践へつなげたこと を説明する要因は何か? 著者らは, この疑問について調べる実地 調査研究から得られた結果を示す. 彼らは, IT の採用プロセスに 開発者を巻き込むこと, IT の導入される環境の特徴, 開発者の管 理問題, そして IT 普及の成功の間の複雑な関係を探究する, 調査 の枠組みを作った.


言語変換の現実性
The Realities of Language Conversions

Andrey A. Terekhov and Chris Verhoef

IEEE Software, Vol. 17, No. 6, November/December 2000

何10億行もの Cobol や PL/I やその他の古いプログラム言語で書 かれたコードが, 今なお利用されている. これらをより近代的な言 語に変換する多くの商業的取り組みが始まったが, ほとんど成功し なかった. 著者らは, いくつかの言語間での変換における要点と, 自動言語変換の可能性と限界のいくつかについて議論する.


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