AbstractClub - 英文技術専門誌の論文・記事の和文要約
AbstractClub - 英文技術専門誌の論文・記事の和文要約 |
|
|
|
IEEE Software (IEEE) Vol.17, No.1
Shari Lawrence Pfleeger and Winifred Menezes
IEEE Software, Vol. 17, No. 1, January/February 2000
我々は, 効果的な技術の伝達に関して, ビジネスコミュニティより
多くのことを学べる. 特に, 異なるタイプの(技術の)採用者の関心
事を理解することで，誰かに納得して革新的な技術を試させるのに
必要な異なる種類の証拠を知ることができる．
同時に法律コミュニティからは，ある革新が現在のやり方に対する
改善であるという説得力のある論拠を組み立てるのに，どのような
種類の証拠が必要とされるかに関する助言を得ることができる．本
稿は，我々が技術選択の決定をなぜ，そしてどのように行うのかに
ついて調べ，またこれらの決定を支える証拠がどのように新しい技
術の採用を助けるか，あるいは妨げるのかについて考察する．
Terri Maginnis
IEEE Software, Vol. 17, No. 1, January/February 2000
我々のほとんど誰も，けしてソフトウェア開発方法論をもって建築 プロジェクトに取り組むことはない．しかし，建築プロジェクトは ソフトウェア開発プロジェクトよりもはるかに高い成功率を示す． Maginnisは，多くのソフトウェア開発プロジェクトにおいてとられ る，『棟梁(master-builder)』手法について明らかにする．その手 法において，開発者はアーキテクト(architect; 建築家)，エンジ ニア(engineer; 技師)，ビルダ(builder; 施工者)，インスペクタ (inspector; 検査官)の役割を担う．ほとんどの大規模建築プロジェ クトは，およそ100年も前にこの手法をやめている．なぜ我々は大 規模ソフトウェアプロジェクトに対してこの手法を用いるのか？ エンジニアがシステム(建物)を設計し，プログラマ(ビルダ)が実装 する．この手法は，品質，納期，予算の点で，より大きな成功率を もたらす．
Helen Sharp, Hugh Robinson, and Mark Woodman
IEEE Software, Vol. 17, No. 1, January/February 2000
社会科学からのアイデアと技法により, ソフトウェア工学分野の定 理と実践を改善することができる．この他花受粉 (cross-pollination)のしてきた貢献を説明するために，著者らは パラダイムとソフトウェア品質管理システムの性質に焦点を当てる． 彼らの研究は，ソフトウェア技術者らがあまりにもしばしば証拠を 求めて好んで議論するにも関わらず，新しい技術的アイデアが受け 入れられるようになる方法におけるコミュニティの重要性と, 局所 的な指導者(local guru)に与えられる形式的な組織構造を超越した 卓越性を強調している．
Peter Hantos and Mario Gisbert
IEEE Software, Vol. 17, No. 1, January/February 2000
世界経済(global economy)の現実により，たとえ現在ソフトウェア 分野が合意の得られたプロセスと品質メトリクスの標準を欠いてい るとしても，米国の製造業はより効果的にソフトウェア開発を管理 する方法を見出すことを強いられている．ソフトウェアの研究開発 における改善をうながすには，学際的な他花受粉 (cross-pollination)手法が個人とグループの編成の中で多くの利 益をもたらすことができる．HantosとGisbertは，建築産業の有名 な教育ビデオを用いて，ソフトウェアプロセス改善に対する，文化 的な，制度上の，そして実装上の障壁を打破する方法を明らかにす る．
Bryan Kocher
IEEE Software, Vol. 17, No. 1, January/February 2000
著者ははじめに，2000年問題と1929年の米国株式市場の恐慌を比較 する．株式市場恐慌に由来する米国会計専門職のための規則とちょ うど同じように，著者は情報システム標準委員会(Information Systems Standards Board)を求めており，そういった組織があれば 2000年問題を避けることができただろう，そして将来もそのような 大失敗が起きることを防げるだろうと主張する．
Karl E. Wiegers and Doris C. Sturzenberger
IEEE Software, Vol. 17, No. 1, January/February 2000
本稿は，ある組織がそのプロセスに関するフィードバックを望んで はいるが，『公式』のCMM評価を行うのに骨の折れる3週間を奉げる ことはできないという，ソフトウェアプロセス評価における共通の 問題に対処するための1つの手法について述べている．このミニ評 価手法においては，調査を特定の関心事に集中させ，労力を組織に 適したレベルに合わせるために，個々の評価構成要素が選択される．
James A. Whittaker
IEEE Software, Vol. 17, No. 1, January/February 2000
著者は，今日のソフトウェア製品のテストがなぜそんなに難しいの かということについていくらか解明し，全てのテスタがきっと完全 に適用することができるであろういくつかの堅実な手法を明らかに する．有能なテスタは，基礎的なテスト技法という貴重なツールキッ トを持っており，その動作環境において製品がどのように用いられ るかを理解し，とらえにくいバグが製品のどこに潜んでいるかを嗅 ぎつける鼻と，パッとそれらをあらわにする一連のトリックを持っ ている．ここに述べられる手法によって，テスタがあるソフトウェ アシステムのテストを終了したと言う時，本当は何を意味している のかという質問に対して，分別をもって答えることができるだろう．
Katrina D. Maxwell and Pekka Forselius
IEEE Software, Vol. 17, No. 1, January/February 2000
本稿は，26のフィンランド企業における206のビジネスソフトウェ アプロジェクトのデータが格納されたある独特なデータベースを使っ て, 生産性の変動の統計分析について考察する．著者らは，銀行， 保険，製造，卸売り/小売り，そして行政機関の領域における生産 性を示す要因に関して，相違点を調べている．著者らは，新しいプ ロジェクトを始める際に予想される生産性を見積もるのにも，それ ぞれのビジネス領域に対する完了したプロジェクトをベンチマーク するのにも役に立つ，生産性ベンチマーク方程式を提案する．
IEEE Software (IEEE) Vol.17, No.2
Bill C. Hardgrave and E. Reed Doke
IEEE Software, Vol. 17, No. 2, March/April 2000
最近のインターネット、Java,オブジェクト指向のトレンドは、 Cobolの占有領域を脅かしているが、Cobol言語とそれを使って保守 のみならず開発をするプログラマは、特にオブジェクト指向Cobol が公式に標準となると、産業においてさらに必要とされ続けるであ ろう。その結果、Cobolトレーニングは優先事項としてとどまる。 Cobolプログラマは、彼らの持つ知識を活用することで、スムーズ にオブジェクト指向開発やJavaプログラミングに移行することがで きる。
Jean E. Sammet
IEEE Software, Vol. 17, No. 2, March/April 2000
よくある神話的通念に反して、Cobolは、1人によってではなくある 委員会によって1959年に最初に作成された。この記事は、Cobol言 語を開発した委員会の創設とミッション、そしてCobolの初期の開 発における幾つかの主な入力と反響について概説し、そして実際に 関わった人々についても含める。この記事の内容は、著者が所有す る1959年の委員会活動の文書に基づいている。
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ベースの機能の両方 をカバーするべきであると指摘している。
Frank P. Coyle
IEEE Software, Vol. 17, No. 2, March/April 2000
レガシーという用語は、Webの広範囲な成功と既存システムを早く インターネットの中に取り込むという要求とに伴い、新たな意味合 いを持ちつつある。Cobolプログラムやデータは、内部連結やコー ドとデータ両方のための内部連結や統合の選択肢を与える新たな可 能性として見られつつある。
Leon A. Kappelman
IEEE Software, Vol. 17, No. 2, March/April 2000
Y2Kは、多くの人々に事業成功(enterprise success)におけるシス テムやソフトウエアの重要性を示し、ソフトウエアのプロフェッショ ナルたちに価値ある教訓を与えた。著者は、IT産業はY2Kからそれ 自体を理解することや、そのソフトウエアシステムをアップグレー ドしたり再設計したりその実践から得られた知識を調べることが必 要であると説いている。
Don Schricker
IEEE Software, Vol. 17, No. 2, March/April 2000
新たなCobol標準、Cobol2002は約18ヶ月で完了すると見られている。 Cobol2002は、Cobolの一次クラスデータのハンドリング機能上で構 築され、オブジェクト指向的特徴、環境上の改良、多くの他の最新 の構成概念(constructs)を言語に導入している。こうした改善の結 果、Cobolはビジネス用言語と、多様なプログラミングの課題を取 り扱う能力のある汎用言語との両方兼ね備えたプログラミング言語 としての位置が得られる。
Brian Henderson-Sellers
IEEE Software, Vol. 17, No. 2, March/April 2000
ビジネスに特化した開発プロセスの利用は、Cobolプログラムの生 産や保守の便宜を大きく向上させることができる。著者たちは、 OPEN(object-oriented process, environment, and notation)プロ セスフレームワークの概要を示す。それは、Cobol言語を用いた実 装を行うビジネス環境において、オブジェクト指向開発かつコンポー ネント指向開発を行うために今日最も適切なプロセスである。その 基礎となるメタモデルとフレームワークによって、OPENは開発と保 守の両方で価値が与えられる。
Edmund C. Arranga, Thane Hubbell, Alden C. Lorents, Steve Shiflett, and Jon Wessler
IEEE Software, Vol. 17, No. 2, March/April 2000
ポストY2Kの最も大きな挑戦の１つに、レガシーリニューアルであ る。しかし一体いくつのツールが使えるのかを知らない。4つのツー ルをここではスポットをあて、新規なGUIのフロントエンドからコ ンポーネントの作成までの、レガシーリニューアルの選択肢の範囲 を示す。ツールの分類リストには、さまざまなツールを100以上カ バーして、そのURLと共に示す。
Elaine J. Weyuker, Thomas J. Ostrand, JoAnne Brophy, and Rathna Prasad
IEEE Software, Vol. 17, No. 2, March/April 2000
信頼性があり頼りがいのあるソフトウエアシステムを成功裏に作成 するためには、効率のよいテストが必要不可欠となる。しかし、あ る個人が能力の高いソフトウエアテスタになる適任者かあるいはそ の潜在能力があるかを決定する形式的な判定基準はほとんどない。 著者たちは、AT&Tにおいて、ソフトウエアテスタが、まず訓練 を受け、認定されたソフトウエアテスト技術者になり、さらにソフ トウエアテスティング専門家に至ることのできるキャリアパスを定 義したプログラムを開発した。
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
Johann Hoerl and Bernhard K. Aichernig
IEEE Software, Vol. 17, No. 3, May/June 2000
軽量なアプローチによって形式開発手法の技術移行が容易になると
いう立場を支持するために, 安全性が重要となる航空管制のための
音声コミュニケーションシステムを, VDM++を使って定義した著者
らの経験について報告する.
[訳注] VDM++: IFAD社が開発したオブジェクト指向の形式言語.
VDM = Vienna Development Method
Daniela E. Herlea Damian, Armin Eberlein, Mildred L.G. Shaw, and Brian R. Gaines
IEEE Software, Vol. 17, No. 3, May/June 2000
面と向かって接することでグループの能力が向上するという信念に 反して, 著者らの研究は, 要求の交渉において, 面と向かってミー ティングするグループの仕事が, テレビ会議とコンピュータ補助を 使うグループと変わりないことを示している.
Carl A. Gunter, Elsa L. Gunter, Michael Jackson, and Pamela Zave
IEEE Software, Vol. 17, No. 3, May/June 2000
著者らは, 形式手法をユーザ要求の構築とシステム機能仕様への落 とし込みに適用するための参照モデルを定義する. 彼らの手法は, システムとその動作する環境の間のインターフェイスを定義する共 有の現象と, このインターフェイスの部品がどのように制御される かに焦点を当てる.
Edward F. Weller
IEEE Software, Vol. 17, No. 3, May/June 2000
定量的手法と統計的プロセス管理をソフトウェア開発プロジェクト に適用することで, プラスのコスト恩恵を受けることができる. 著 者は, テストの定量分析と, テストにおいて製品品質を評価し, ソ フトウェアのメジャーリリースに向けて出荷後の製品品質を予測す るためのテストデータを用いた.
Luigi Lavazza
IEEE Software, Vol. 17, No. 3, May/June 2000
計測はソフトウェア開発を管理し改善するための重要な要素である. 本稿は, Goal Question Metrics(GQM)計測プロセスの最も高価なフェ イズの自動化について説明する. 特に著者は, 計測の定義, 収集, 解析, フィードバックのためのツール, そしてこのツールと構成管 理システムやメトリクスツールを連携させるテクニックについて述 べている. これらのテクニックは, ある産業の場面において実施さ れた計測プログラムにおいて使われた.
Daniel Jackson and John Chapin
IEEE Software, Vol. 17, No. 3, May/June 2000
1998年の秋, 著者らは, NASAにより開発され, 現在アメリカ合衆国 のいくつかの空港で採用されている航空管制システム CTAS の1コ ンポーネントを再設計した. このケーススタディは, 基本的なソフ トウェア工学のテクニックによって, いかに複雑なシステムを劇的 に単純化することができるかを示している. 著者らは, 航空管制シ ステムを様々なツールを用いてリバースエンジニアリングし, より 小さくより単純でそしてより柔軟なものへと再設計することから学 んだ教訓について述べる.
Allan Baktoft Jakobsen
IEEE Software, Vol. 17, No. 3, May/June 2000
ソフトウェアビジネスは骨が折れる. それには正しい製品だけでな く, 正しい開発プロセスも必要である. 本稿は, ある破滅的ソフト ウェア製品のリエンジニアリングと, 開発者が使った2つの異なる リエンジニアリングプロセスについて述べる. 著者は, 片方のプロ セスが失敗し他方が成功した理由について説明し, ソフトウェア開 発においては人とプロセスが調和しなくてはならないと主張する.
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世大学の計算機科学 クラスを教えた初期の経験について述べ, そこから学んだ教訓につ いて議論する. 彼らはまた, 実際の計算機科学教育にフリーソフト ウェアを使った理由について論ずる.
Natalia Juristo, Ana Maria Moreno, and Marta Lopez
IEEE Software, Vol. 17, No. 3, May/June 2000
オブジェクト指向手法をソフトウェア開発に適用する制限の1つは, オブジェクト指向分析のプロセスが未成熟であることだ. 本稿は, このプロセスの過程で適用される, 非形式的な仕様からの言語情報 の使用に基づいたアプローチを提案する. 提案された手法はこの情 報を意味的にそして文法的に分析するのを助け, 準形式的な手続き を用いて, そういった分析からオブジェクト指向システムのコンポー ネントを抽出する.
Ramkumar Ramaswamy
IEEE Software, Vol. 17, No. 3, May/June 2000
保守プロジェクトのチーム規模は, 保守要求の発生する頻度と, そ れぞれの要求に対して迅速に対応することの重要性に依存する. 著 者は, この考えに基づいた, 保守プロジェクトの人員配置のための 5段階の手法を示す. その手法は, 使いやすい検索テーブルとして 提供される待ち行列モデルからの結果を用いる. そしてこの結果は 経験的かつ質的な入力を使って洗練され, 有用で実際的な人員配置 の見積もりをもたらす. 著者は, ある実際のプロジェクトからのデー タを用いて手法を説明する.
IEEE Software (IEEE) Vol.17, No.4
Laurie Williams, Robert R. Kessler, Ward Cunningham, and Ron Jeffries
IEEE Software, Vol. 17, No. 4, July/August 2000
ソフトウエア産業は、ペアプログラミング-二人のプログラマは協 力して1つのコンピュータで１つの問題を作業するということを、 何年も実践したきた。しかし、これを試したことのない人は、資源 の無駄であるとしてこの考えを多くの場合拒絶する。著者は、ペア プログラミングは、より短い時間で良いソフトウエア製品を生み出 し、また仕事に満足し自信を持ったプログラマを生むということを 示す。こうしたペアプログラミングを支持する証拠は、プロフェッ ショナルなプログラマから、そして大学生で行なった実験から得ら れる。
Linda Rising and Norman S. Janoff
IEEE Software, Vol. 17, No. 4, July/August 2000
今日のソフトウエア開発をめぐる環境において、製品開発のライフ サイクル期間中に揺れ動くビジネス要求に合わせるため、要求仕様 はしばしば変更される。このことは、開発チームの頭痛の種となっ ている。著者たちは、この問題に取り組み、AG通信システムからス クラム‐ソフトウエア開発プロセスを実現した彼らの経験を議論す る。スクラム‐ソフトウエア開発プロセスを経験した中で、彼らは 適切なスクラムの変形を定義し適用することで、小さなチームが柔 軟で適応し易くできることを明らかにした。
Stanley M. Sutton, Jr.
IEEE Software, Vol. 17, No. 4, July/August 2000
この記事では、商業ソフトウエアのスタートアップ(操業開始)にお けるプロセスの役割について議論する。まずスタートアップの特徴 とスタートアップしたばかり企業と確立した企業との間の違いを明 らかにした後、著者は、確立した企業とは異なる理由と方法になる けれども、スタートアップでおいてプロセスに注意を払うべきと結 論付ける。本記事は、スタートアップした企業が、その組織内部で プロセスに取り組み改善することができる方法を提案している。
Donna L. Johnson and Judith G. Brodman
IEEE Software, Vol. 17, No. 4, July/August 2000
今日多くの組織が、SEI(Software Engineering Institute)のソフ トウエア成熟度モデル(CMM:Capability Maturity Model)を使って、 データベースを開発し、市販製品をインストールし、サービスを提 供し、あるいは保守を行なっている。小規模な組織あるいは、小規 模なプロジェクトからなる組織もまた成熟度モデルを使おうとして いているが、彼らの従来とは異なる開発業務にCMMを適用する難し さを予期している。著者たちはこうした組織が、CMMの実践を教義 (gospel)として扱うのではなく、CMMの趣旨に焦点を当てて彼らの プロジェクト計画作成プロセスをどのように改善するかを示す。
Lisa Brownsword, Tricia Oberndorf, and Carol A. Sledge
IEEE Software, Vol. 17, No. 4, July/August 2000
商用の技術や製品を使ってシステムを開発することは一般的になっ てきている。アプリケーション開発者は、システムの新規開発や保 守に対するダイナミックな原則やプロセスをよりよく理解するよう にならなくてはならない。今日彼らは、COTS(Component On The Shelf)製品が既存のシステム開発プロセスにどのように影響を及ぼ すか、あるいは新たなプロセスが必要なのかについての情報をほと んど持っていない。 Software Engineering Instituteに属する著 者たちは、COTSベースのシステムを開発あるいは保守するための新 しいプロセス要素と変更したプロセス要素を示す。
Maurizio Morisio, Colin Tully, and Michel Ezran
IEEE Software, Vol. 17, No. 4, July/August 2000
著者たちは、計画的再利用(systematic reuse)を達成する、4つの 会社から示されたプロセスを示し、さらにそれらを比較する。これ らの会社は、規模やビジネス領域、開発アプローチが異なっている。 しかし、基本的なプロセスや技術がまったく異なっているにも関わ らず、全て再利用の目標を達成している。この記事では異なるプロ セスで成功させたキーとなる理由を議論する。そこには、マネージ メントが強力に関与したことや、変更に対する問題を明確にし注意 を払ったこと、そして変更を最小限にすることを含まれている。
Alistair Cockburn
IEEE Software, Vol. 17, No. 4, July/August 2000
様々な方法論はそれぞれ必然性があり、何が方法論を構成している のかと、何が方法論の基礎とする原則なのかという疑問から直接生 じる。サイズや構成、特性そして危険性によってもプロジェクトが 異なってくる。プロジェクトに関わる人々は、彼らの経験や規範あ るいは心配事に基づいて、それぞれ偏りを持っている。これらの問 題を統合してプロジェクトを超える最適なものとする。この記事で は、いつより重量級の方法論あるいはより軽量級の方法論を選択す るための原則、方法論の差別化のフレームワーク、そしてこれらの アイデアを使ったプロジェクト経験について報告する。
Gargi Keeni
IEEE Software, Vol. 17, No. 4, July/August 2000
Tata Consultancy Services社(TCS)は、90年代初期から様々な品質
モデルに対して自社のベンチマーキングを行なってきている。すべ
てのTCS開発センターでは1995年以降ISO9001の認証を受けてきた。
インドにある17の開発センター中、7つのセンターはCMMで最高ラン
クの5レベルと評価され、1つのセンターは4レベルと評価された。
TCSは1996年にCMMによる自社のベンチマークを開始したが、その品
質主導の基盤は、80年代にさかのぼって築かれた。この記事では、
ここに至った経緯と得られた教訓を述べる。
ISO9000主導は監査プロセスを規定し、組織レベルで品質管理シス
テムを設ける手段となる。定量的プロセス管理は、統計的プロセス
管理によるプロセス能力への組織的な見通しを提供する。CMM V1.1
のレベル5の主要プロセス領域は、繰り返し作業の減少することと
新たなプロセスや技術の評価することへのフレームワークを提供す
る。
Bill Pitterman
IEEE Software, Vol. 17, No. 4, July/August 2000
巨大で多面的な会社が、ISO9001への登録とプロセスのCMMレベル5 への格付けの両方を成し遂げながら、品質や顧客満足は結果論とす る文化から、これらの要素が会社の主体であるソフトウエア開発ビ ジネスの背後で突き動かす力となっている文化にどのように変わる のであろうか？Telcordia Technologiesは、5年間にわたってこう した社内制度全体を変化させた。
William A. Florac, Anita D. Carleton, and Julie Barnard
IEEE Software, Vol. 17, No. 4, July/August 2000
より効率的で有効性があるソフトウエアプロセスへの要求が増大し ており、ソフトウエア工学コミュニティに対して、従来行なわれて きたこと以上に計測を重視することを求めている。統計的そしてプ ロセス思考の原則は、ソフトウエア開発に使われるプロセスの一貫 性と能力を決定付けるために統計的プロセス管理手法を使うことを 導く。この記事は、SEI(Software Engineering Institute)と スペー スシャトル搭載ソフトウエアプロジェクト(Space Shuttle Onboard Software Project)との技術的な共同作業に基づくものである。統 計的プロセス管理を使いプロセスの挙動を分析することに関連する 分析的な要因について、これらの要因の役割を説明する手段である インスペクションプロセスを使って議論する。
IEEE Software (IEEE) Vol.17, No.5
Gary McGraw and Greg Morrisett
IEEE Software, Vol. 17, No. 5, September/October 2000
加速する相互接続性, 複雑さ, 拡張性の傾向は, 悪意のあるコード によってもたらされるとっくに深刻になっている驚異を悪化させて いる. 悪意のあるコードと戦うために, 著者らは, ソフトウェアの 振る舞いに関するしっかりとしたポリシーを作ることと, 技術的な 手段を通してそのポリシーを実施することを強く訴える.
John McHugh, Alan Christie, and Julia Allen
IEEE Software, Vol. 17, No. 5, September/October 2000
侵入検知システム(IDS)は, コンピュータシステムとネットワーク を悪用から守るための防御対策の重要なコンポーネントである. 本 稿は, 組織の全体的な防御姿勢における IDS の役割について考察 し, IDS の配置, 運用, 保守に関するガイドラインを示す.
John R. Michener and Tolga Acar
IEEE Software, Vol. 17, No. 5, September/October 2000
大規模システムにおいて, より上位の構造の中で要所を分割するこ とが必要になってくる. これらの構造をセキュリティドメインとし て確立し管理するには, ローカルサービスを安全に提供するための 基盤構造が必要である.
Thomas F. Bowen and Mark E. Segal
IEEE Software, Vol. 17, No. 5, September/October 2000
Telcordia Technologies と Stony Brook のニューヨーク州立大学 の研究者達は, 素早い開発と実時間防御の展開によって, アプリケー ションのセキュリティホールにつけこまれるのを防ぐための新しい 能力を, コンピュータ利用者に提供するアプローチについて研究し ている. 彼らの解決策は, アプリケーションの要求するシステムコー ルを横取りすることによるアプリケーションの振る舞いの監視と変 更を含んでいる.
John Viega, Tom Mutdosch, Gary McGraw, and Edward W. Felten
IEEE Software, Vol. 17, No. 5, September/October 2000
開発者も利用者もアプリケーションのセキュリティホールに関して ある程度の保証を要求する. 著者らは, プログラマが自動的に既存 のセキュリティに関する知識を利用できるようなツールのプロトタ イプ Jslint を設計した.
Tore Dyba
IEEE Software, Vol. 17, No. 5, September/October 2000
ソフトウェア開発およびソフトウェアプロセス改善の従来のやり方 は, 環境が予測可能であることを仮定した理論に基づいている. し かし, ほとんどの小さなソフトウェア開発組織にとって, 環境は絶 えず変わっていてしばしば予測できないものである. 著者は, 即興的手法 と小さな会社におけるその役割について探究する.
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ヶ月間のプロジェクトの仕事から得られ た最初の体験と教訓について述べている. また各社における最初の 結果も含む.
Melissa L. Russ and John D. McGregor
IEEE Software, Vol. 17, No. 5, September/October 2000
著者らの開発プロセスは, 反復的インクリメンタルプロセスモデル の一部と, それぞれのプロセスフェイズにおける品質を評価する品 質保証プロセス, およびプロセス改善を手引きするためのデータ収 集を行う計測プロセスを統合する. そのプロセスの目的は, 小さな プロジェクトに大きなオーバーヘッドを強いることなく, 今日の市 場で要求される高い品質と時期を得た結果を生み出すことである.
Vaclav Rajlich
IEEE Software, Vol. 17, No. 5, September/October 2000
非常にしばしば, ある企業が他人のソフトウェアを引き継いだもの の, 悲しいことに文書が足りないことにただ気づくばかりとなって しまう. この報告は, ある小さなソフトウェア会社が, どのように, Webベースの分割された注釈(Web-based Partitioned Annotations) を使って, 引き継いだあるソフトウェアアプリケーションを, コス トパフォーマンスよく展開させたかについて述べている.
Tim Menzies and Bojan Cukic
IEEE Software, Vol. 17, No. 5, September/October 2000
著者らは, 多くの小規模プロジェクトにとって, ランダムに選ばれ た少数のテストで十分にソフトウェアを調べることができると主張 する. 彼らは, 限られた資源での素早いテストが, 念入りでお金の かかるテスト体制と同じくらい効果的かどうかを決定するのに, プ ログラムの形状がどのように役立つかを議論する.
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
James Bielak
IEEE Software, Vol. 17, No. 6, November/December 2000
著者は, 完了したC++のプロジェクトについて調査し, 我々が容易 に要求仕様や初期のクラス設計に遡ることができるようなプログラ ミング成果物について考察する.
Stefan Biffl
IEEE Software, Vol. 17, No. 6, November/December 2000
本稿は個人の見積もりから導かれる主観的チーム見積もりモデルを 提案し, 検査データに基づく欠陥見積もりモデルの正確性について 調査する.
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 のいず れにおいても, その予測能力が大きく向上することを示す.
Philip M. Johnson, Carleton A. Moore, Joseph A. Dane, and Robert S. Brewer
IEEE Software, Vol. 17, No. 6, November/December 2000
ハワイ大学における LEAP プロジェクトは, 低コストで経験に基づ いたソフトウェア開発者の向上をサポートするツールと手法につい て研究している. 最近の事例は, 低コストな分析手法により与えら れた場合に, 推量が最も正確な手法となることの証拠を示している.
Donald J. Reifer
IEEE Software, Vol. 17, No. 6, November/December 2000
開発者は, Web Objects と呼ばれる新しいメトリクスと, WebMo と 呼ばれる Cocomo II の改作を使って, より正確に, Web ベースの ソフトウェア開発における工数と期間を見積もることができる.
Bradford K. Clark
IEEE Software, Vol. 17, No. 6, November/December 2000
組織が多くの改善を並行して実施するとき, 管理者には, その他の 要因に対して, どの程度の改良がプロセスの成熟度によるものなの か決定するすべがない. 本稿は, 161 のプロジェクト例を使って, プロセスの成熟による活動の効果を, 他の効果から分離する.
Xiaoming Zhong, Nazim H. Madhavji, and Khaled El Emam
IEEE Software, Vol. 17, No. 6, November/December 2000
個人のソフトウェアプロセスの品質は, ソフトウェアプロジェクト と組織の成功を決めるのに役立つ. 著者らは, 個人のプロセスに影 響する要因について深く掘り下げる.
Jagadish Kamatar and Will Hayes
IEEE Software, Vol. 17, No. 6, November/December 2000
本稿は, 数年間にわたり2つの産業プロジェクトのからみでパーソ ナルソフトウェアプロセス(Personal Software Process)を使用し た, 第一著者の体験について報告する. この実体験より得られた説 明では, 教育, 初期の使用, その後の PSP 技法の採用について取 り上げ, 欠陥データの分析と取られた修正活動についても言及する.
Maurizio Morisio
IEEE Software, Vol. 17, No. 6, November/December 2000
著者は PSP をある企業に導入した経験について報告している. 導 入後1年が過ぎ, PSP のごく一部は今なお使われている. PSP は, プロセス改善活動を喚起するモデルとして, 何の変更もなく再利用 される既存のプロセスよりも役に立つことが証明された.
Gina C. Green and Alan R. Hevner
IEEE Software, Vol. 17, No. 6, November/December 2000
新しいソフトウェア開発技法をうまく普及して実践へつなげたこと を説明する要因は何か？ 著者らは, この疑問について調べる実地 調査研究から得られた結果を示す. 彼らは, IT の採用プロセスに 開発者を巻き込むこと, IT の導入される環境の特徴, 開発者の管 理問題, そして IT 普及の成功の間の複雑な関係を探究する, 調査 の枠組みを作った.
Andrey A. Terekhov and Chris Verhoef
IEEE Software, Vol. 17, No. 6, November/December 2000
何10億行もの Cobol や PL/I やその他の古いプログラム言語で書 かれたコードが, 今なお利用されている. これらをより近代的な言 語に変換する多くの商業的取り組みが始まったが, ほとんど成功し なかった. 著者らは, いくつかの言語間での変換における要点と, 自動言語変換の可能性と限界のいくつかについて議論する.
リコー
AbstractClub