AbstractClub - 英文技術専門誌の論文・記事の和文要約
AbstractClub - 英文技術専門誌の論文・記事の和文要約 |
|
|
|
IEEE Software (IEEE) Vol.19, No.1
Anthony Hall, Roderick Chapman
IEEE Software, Vol. 19, No. 1, pp. 18-25 , January/February 2002
つい最近、プラクシス・クリティカル・システムズ（Praxis Critical Systems）社は、厳格なセキュリティの制約を満たしつつ性能と使いやすさの要件を満足しなければならないスマートカードのための安全な認証局を開発した。 著者らは要件抽出から、フォーマルメソッドを用いた仕様、ユーザインターフェースのプロトタイピング、厳密な設計、そしてコーディングに渡って体系的なプロセスを用いることによって、これらの目標を確実に達成した。 彼らは標準的な商用の生産性を達成するプロセスが、スループットと使いやすさの目標を全て達成した高信頼システムをどのように生み出せるのかを示す。
HT
Jonathan S. Shapiro, Norm Hardy
IEEE Software, Vol. 19, No. 1, pp. 26-33 , January/February 2002
設計原理はソフトウェアの構築において最も支持されている考え方のひとつである。しかし、体系的に導入されたことはほとんどない。 それらは特にセキュア・信頼システムにおいて重要である。 一から構築されたオペレーティングシステムであるEROSは、形式的に検証できるセキュリティ、実用的な信頼性、高い性能を提供する。 この記事ではEROS構築の基となっている主要な設計原理、これらの原理が設計に与えた影響、結果としてできあががったシステムから自然に浮かび上がったアプリケーションの構造、この構造がシステムのセキュリティやテスタビリティにどう影響を与えたか、について述べている．
HT
Khaled M. Khan, Jun Han
IEEE Software, Vol. 19, No. 1, pp. 34-41 , January/February 2002
この記事ではセキュリティにおける重要な問題を扱う。その問題とは、コンポーネントベースのソフトウェア開発環境において、他者に対してソフトウェアコンポーネントのセキュリティ特性を開示することにより、いかに信頼を与えるかということである。 著者らはこの試みにおけるコンポーネントセキュリティを特徴付けるフレームワークを紹介する。そのフレームワークは他者にソフトウェアのセキュリティのプロファイルをさらすことでセキュリティ特性を特徴付ける。 活発な交流によりソフトウェアエンジニアは構成物の候補であるコンポーネントのセキュリティ特性による影響を事前に知ることができる。
HT
David Evans, David Larochelle
IEEE Software, Vol. 19, No. 1, pp. 42-51 , January/February 2002
ほとんどのセキュリティ攻撃は実装上の欠陥がよく知られたクラスのインスタンスを不当に利用する。 開発者はソフトウェアを配置する前にこれらの欠陥の多くを発見し除去することができるかも知れないが、これらの問題は憂慮すべき頻度で発生する。それはセキュリティコミュニティが十分に問題を理解していないからではなく、ソフトウェア開発プロセスにそれらを防ぐ技術が組み込まれていないからである。 この記事は一般的なセキュリティの脆弱性（バッファオーバーフローや書式文字列の脆弱性を含む）を検出するための軽量静的分析を利用した、拡張可能なツールについて述べたものである。
HT
Rob Pooley, Dave Senior, Duncan Christie
IEEE Software, Vol. 19, No. 1, pp. 52-58 , January/February 2002
実際のプロジェクトデータから生成されたメトリクスは、性能の評価や指針のための価値のあるツールを提供する。 著者らはWebベースのプロジェクトメトリクスシステムの開発、およびその採用を促進した自分たちの経験を述べている。 また、彼らはそのようなシステムがどのように企業の中にメトリクスの採用を促進させ得るかを考察する。
HT
Tiffany Winn, Paul Calder
IEEE Software, Vol. 19, No. 1, pp. 59-66 , January/February 2002
現在の風潮で、パターンがよく誤った専門用語として使われている。 そうであるにもかかわらず、パターンらしさの明確な定義は存在しない。おそらく、パターンが規範的，形式的定義にそぐわないからである。 著者らはパターンらしさの検証に用いることができる一連の特徴を提案する。 彼らの検証における各特徴は、デザインパターンの本質的な側面を述べている。 これらの特徴を知ることは、ソフトウェア設計者がより良いパターンを理解、使用、作成するための助けとなるであろう。
HT
Rick Kazman, Len Bass
IEEE Software, Vol. 19, No. 1, pp. 67-73 , January/February 2002
この記事では公式のアーキテクチャレビューの非技術的な側面である、社会的、心理学的、経営的側面を探求する。 アーキテクチャーレビューは、システムの事業目標と密接な関係があるという点において他の技術レビューとは異なっている。そのため、異なったアプローチが必要となる。 著者らは、彼ら自身の幅広い種類のアプリケーションドメインにおけるソフトウェア、システムアーキテクチャのレビュー、検証の経験から教訓を得る。 彼らはそのようなレビューを運用する際にアーキテクトが直面する問題、避けるべき一般的な落とし穴、組織がレビューを成功させるチャンスを増やすための方法について議論する。
HT
Evgeni Dimitrov, Andreas Schmietendorf, Reiner Dumke
IEEE Software, Vol. 19, No. 1, pp. 74-83 , January/February 2002
情報システムの時間とリソースに関しての性能は、ソフトウェア開発で選択された設計に大きく左右される。 性能工学の中心となる考え方は、最初期の開発フェーズからソフトウェアシステムの性能要因を説明することである。 不運にもこれらの手段は、ソフトウェア開発の間に明示的には行われていない。それは主に締め切りへのプレッシャー、情報システムの複雑さ、性能工学が意味することへの知識不足が原因である。 著者らはUMLベースの性能工学を概観し、類似するアプローチを分析し、利用できるツールの有効性を検証する。
HT
IEEE Software (IEEE) Vol.19, No.2
活動を休止しておりました．
IEEE Software (IEEE) Vol.19, No.3
Steve McConnell
IEEE Software, Vol. 19, No. 3, May/June 2002
ほとんどの私のコラムでは、私が知っているトピックスについて書いている。 私は自分が知らないトピックスがどれだけたくさんあるかだんだん気付くようになってきた。 このコラムでは、私が個人的にもっとも答えたかったいくつかの疑問について述べよう。
YY
Donald J. Reifer
IEEE Software, Vol. 19, No. 3, May/June 2002
ナレッジマネジメントはソフトウェアプロジェクトをより上手に管理するために役立つのだろうか。 私は、近年の研究の結果から確かに役立つと結論付けた。この要点について説明するために、 ソフトウェア管理者が果たす古典的な役割を中心に構成化されたナレッジマネジメントの潜在的な利点と欠点のリストを表1 に示した。
YY
Chris Rupp
IEEE Software, Vol. 19, No. 3, May/June 2002
顧客の興味を満足させられるかどうかで、市場で成功できるかどうかがが決まる。 しかし、要求を効果的かつ効率的に発見するにはどうしたらいいのだろう。 この質問は簡単なようだが、日々の実践の中で答えるのは難しい。 しばしば、ステークホルダーは要求についてインタビューを受けたり、それらを文書化するよう要請されるが、 このアプローチで顧客の本当の関心やニーズを反映した真の要求をカバーできることは稀だ。 我々は、顧客の本当の要望（顧客が気づいているもの、気づいていないもの、潜在的であるものでさえ） についての情報を得る方法を必要としている。 最もよく売れる製品とは、これらの要望を満たしたものなのだ。
YY
Martin Fowler
IEEE Software, Vol. 19, No. 3, May/June 2002
多くのプログラマにとってのパフォーマンスとは、プログラムしているときでも常に注意を払うものだ。 そして、プログラムの一部を書くたびにパフォーマンスの影響を考えて、パフォーマンスを最大化するようなコードにする。 これは明白なテクニックだが、残念ながら殆どうまくいかない。
YY
Dave Thomas, Andy Hunte
IEEE Software, Vol. 19, No. 3, May/June 2002
ユニットテストのコード作成が大変な理由の一つに、実世界の出来事が常にでしゃばってくることが挙げられる。 もしも、我々がしなければならないことが、 配列のソートやフィボナッチ数列を生成するメソッドのテストコードの作成だけであったなら、 人生はどんなに簡単であっただろうか。 だが、実際にはデータベース、通信機器、ユーザインタフェースや外部アプリケーション を使うコードをテストしなければならない。 さらには、まだ利用できないデバイスと接続したり、ローカルでの生成が不可能なネットワークエラーをシュミレートしなければならない。 これらすべての要因が我々のユニットテストが整然とし、独立した（かつ直交した）コードの 断片になるのを妨げようとする。 その代わりに、我々がちょっとでも注意を怠れば、 実行に必要なコンテキストをテストに与えるためだけに、ついついほぼすべての各システムコンポーネントの初期化を やり終ええるようなテストを書いてしまう。 これは、時間を消費するだけでなく、テストプロセスに途方も無い量のカップリングを作り出す。 たとえば、誰かがインターフェースやデータベーステーブルを変更したら、突然、あなたの貧弱で小さなユニットテストのセットアップコードは不可解なことに死んでしまうなんてことが起きる。 こんなことが数回も起きれば、やる気に満ちた開発者でさえくじけてしまう。 ついには、テストは行われなくなり、どういう結果になるかは我々皆が知るとおり。
YY
Ioana Rus, Mikael Lindvall
IEEE Software, Vol. 19, No. 3, May/June 2002
ソフトウェア組織の中心的な資産とは、設備でもなければ、建築物でもなく、高価な機械でもない。 中心的資産とは、コンサルティングや法律、投資銀行、それに広告業のような分野と同じく、それ自身の知的資産である。 知的財産の主な問題は足を持っていて、毎日、家に帰ってしまうことだ。 経験はドアから出て行くし、同じ割合で無経験はドアから中に入る。 多くのソフトウェア組織は、それを認めようがそうでなかろうが、契約を勝ち取り、事業を遂行するのに必要な能力 レベルを持続するという課題に面している。
YY
Jay Liebowitz
IEEE Software, Vol. 19, No. 3, May/June 2002
世の中が情報の時代から知識の時代へと移行するとともに、知識が重要資産として扱われつつある。 NASAとその他の組織は、彼らの組織の可能性を最大限に活かすために、彼らの知識や知的財産を十分に活用しなければならないことを理解している。 この課題を成し遂げるために、 組織内にナレッジ・マネジメントとナレッジ・シェアリングの構想を立ち上げることが流行しつつある。 たとえば、NASAは NASAの代表者で構成されるナレッジ・マネジメントチームを組織した。 NASAゴダード宇宙飛行センター(GSFC, Goddard Space Flight Center)には、専門家と知識の保有面で進行中のいくつかのナレッジ・マネジメント構想がある。
YY
Andreas Birk, Torgeir Dingsoyr, Tor Stalhane
IEEE Software, Vol. 19, No. 3, May/June 2002
事後分析(PostMortem Analysis, PMA)は、ナレッジ・マネジメントを始めるための実践的な方法の一つで、完了したプロジェクトから経験と改善案を取り込む。 PMAは、ほとんど労力をかけずに、初期の効果がすぐに得られるので小・中規模のプロジェクトや会社にさえふさわしい。 著者らは、彼らがソフトウェア組織の経験の収集と分析に、PMAテクニックを適用した経験について記述する。
YY
Kurt Schneider, Jan-Peter von Hunnius, Victor Basili
IEEE Software, Vol. 19, No. 3, May/June 2002
ソフトウェア開発と獲得プロセスの改善、そして過去のソフトウェアプロジェクトからの知識の明示的な再利用に取り組むために ダイムラークライスラー社は、ソフトウェア経験センター(Software Experience Center, SEC)を作った。 SECは経験の再利用（ナレッジ・マネジメントの一種）の調査と収集した経験のSPI(Software Process Improvement)への適用を目的とする。 著者らは SFCの構築において企業が直面した課題について報告する。
YY
Balasubramaniam Ramesh
IEEE Software, Vol. 19, No. 3, May/June 2002
トレーサビリティとは断片化した知識の源をつなぎ合わせる接着剤のようなものだ。ソフトウェアの開発組織においては、 プロセスについての知識の生成、蓄積、発見、移転、適用を助ける。 ここでは、大規模な実験による研究の結果をもとにして、重要なナレッジマネジメントプロセスの促進におけるトレーサビリティ の役割の模範例を示す。
YY
Shivram Ramasubramanian, Gokulakrishnan Jagadeesan
IEEE Software, Vol. 19, No. 3, May/June 2002
ナレッジマネジメントはソフトウェア工学に重要だ。 なぜなら、うまく従業員が持つ知識を展開・利用するために、組織は単なる人的資本以上のものを必要としている。 知識はただかもしれないが、効果的に利用し、管理しようとすればそうはいかない。 この記事では、ナレッジマネジメントの重要性と利得を強調して、Infosys におけるナレッジマネジメントの実践をレビューする。
YY
Chih-Ping Wei, Paul Jen-Hwa Hu, Hung-Huang Chen
IEEE Software, Vol. 19, No. 3, May/June 2002
ナレッジ中心の新興の経済制度で競争するために、世界中のビジネス組織が知識管理のための様々な構想を立ち上げた。 著者らは、ナレッジの成文化手法に従って知識管理の集積回路の組み立て検査会社に直面する課題に挑戦した。 これらの課題は、集積回路の組み立てテストについての安定した習得、構造化、共有、そして過去のデザイン・レビューと顧客サービスから学んだ重要な教訓の利用についてのものだ。 これらの課題は、集積回路の組み立てテストについて、過去のデザイン・レビューおよび顧客サービスから学んだ重要な教訓を、確実に獲得し、形式化し、共有し、利用することについてのものだ。 この記事では、著者らのシステムアーキテクチャ設計について説明し、ナレッジの共有支援、生産性改善、そして顧客関係管理(CRM, Customer Relationship Management)の向上を含んだいくつかの領域における好意的な事前評価の結果にスポットを当てる。 また、我々の研究成果に基づいて、ソフトウェア工学における知識管理についての重要な示唆についても議論する。 ソフトウェアエンジニアリングでは、知識の共有と再利用は、最終的な設計品質や組織生産性、サービスレベルに対して同じくらい重大である。
YY
Seija Komi-Sirvio, Annukka Mantyniemi, Veikko Seppanen
IEEE Software, Vol. 19, No. 3, May/June 2002
ソフトウェア開発組織は重要知識の収集と再利用という問題を抱えていた。 ソフトウェアプロジェクトは短期的な目標に傾倒しており、知識を発見することも、知識を他者に提供することもできなかった。 データベース駆動のアプローチは結局は完全な失敗に終わった。 データベースによる手法よりもグループメンバー間の知識共有イベントの方が、知識共有のより優れた方法であると明らかになったものの、これらのイベントの結果は将来のプロジェクトのためにまとめることも再利用することもできなかった。 これに対して企業の取った解決策は、丁度良いタイミングで知識を伝達するためのニーズに基づくアプローチを開発することであった。
YY
Sheila Guilford, Gordon Rugg, Niall Scott
IEEE Software, Vol. 19, No. 3, May/June 2002
この記事では、人間の知覚におけるバイアスについて述べる。 このバイアスは、一般的には製品評価において、特にソフトウェア評価において、実際的かつ道徳上の影響を持つ。 バイアスは、ユーザがある体験が全般的にどのくらい愉快あるいは不快であったかを思い出すのに影響する。 この思い出は、体験の中で最も強烈なエピソードや最後の数分の体験によって歪められてしまう。 結果として、ユーザの体験についての思い出は、彼らが体験している間に感じたことから、著しく異なるかもしれない。 このことは、他の分野と同様、ユーザビリティのデザインやデバッギング戦略に、実際的かつ道徳上な影響を持つ。 著者らはその効果について述べ、ソフトウェア工学に対する影響について議論する。
YY
Gerald Ebner, Hermann Kaindl
IEEE Software, Vol. 19, No. 3, May/June 2002
リエンジニアリングの分野において、著者らは（仕様を通じたコードからコードへの）完全なトレーサビリティに賛同する。 彼らは、レガシーソフトウェアシステムのリバースエンジニアリングとその後に続く再設計、再実装の過程で、トレーサビリティがリエンジニアリングに特有と思われる恩恵を即座にもたらすいくつかの事例を発見した。
YY
Michael S. Guntersdorfer, David G. Kay
IEEE Software, Vol. 19, No. 3, May/June 2002
COTS(Commercial-off-the-shelf, 商用ですぐに利用できる)ソフトウェアコンポーネントは、将来のソフトウェア開発において重要な技術と考えられている。 しかし、その潜在的な利益に比べると、市場での成功は芳しいものではなかった。 部品間の相互接続性のような技術的な障害の克服に対しては多くの試みがなされたが、ビジネスモデルに関してはほとんど注目されなかった。 この記事では、いかに 機能的に類似したソフトウェアコンポーネントの節度のない蔓延が、技術的、経済的に不利であるかについて議論する。 ソフトウェア特許を既存技術の新たな応用あるいは効果的な技術改善のどちらかに集中することで、この蔓延を遅らせることができる。 また、これはコンポーネントベースソフトウェアの再利用を促進し、COTSソフトウェアの弱点であるビジネスモデルを強固にすることにもなるだろう。
YY
Carlos H.C. Duarte
IEEE Software, Vol. 19, No. 3, May/June 2002
ほぼ10年前に、ブラジルの科学技術省の研究部門であるCNPq(ブラジル国立科学技術開発評議会)は、 教授、事業家、政策立案者から成るコミュニティを召集した。 このコミュニティの目的とは、既存のブラジルの情報技術政策に最終的に置き換える 戦略プログラムを定義することであった。 当時、厳格な政策が国内市場を規制し、 国内で生産されたものと類似した海外からの輸入品に対して多くの規制を課すことで国内のIT産業を保護した。 国内のグループとグローバルな生産者との間に結ばれた既存のパートナーシップはハードウエアの製造を支援したが、 ソフトウェアは付属品としてしか扱われなかった。 コミュニティは、具体的な相互関係のある活動を提案した。 この活動の狙いは、国家のコンピュータと人的資源情報インフラの改善、 共同の基礎研究・開発の育成、ソフトウェアと輸出品にフォーカスした国産のIT産業の開発であった。 我々の以前の研究成果は、コミュニティのこれらの活動の実施について詳しく述べている。 ここでは、この計画の結果について分析する。
YY
John Steven
IEEE Software, Vol. 19, No. 3, May/June 2002
プロジェクト管理は、ソフトウェアの品質保証をテスト要員の専門技能を当てにする。 だが、契約上および管理上の課題もまたプロジェクトの品質に影響する。 そのような課題は、テスト自体さえコントロールするかもしれない。
YY
IEEE Software (IEEE) Vol.19, No.4
Paul Clements, Charles Kreuger
IEEE Software, Vol. 19, No. 4, pp.28-31, July/August 2002
主旋律(要点)：先を見越しておく(proactive)ことが功を奏する
ソフトウェアプロダクトラインは，コスト，スケジュール(納期)，品質において真の大規模改善をもたらす，ソフトウェア工学における上昇中のパラダイムを表す．この分野が成長し，成熟するにつれて，事例研究がより豊富かつ有益になってきている．書籍，論文，学会，ワークショップ，そして本誌のような雑誌の特集が，我々を刺激する考えを示してくれる．
対位旋律(対照的な論点)：採用の障壁を取り除く
成功したソフトウェアプロダクトライン展開の話は，しばしば冒険叙事詩のように読める．最後は霊感的な部分の勝利に終わるのだが，旅の途中には，危険，困難，犠牲，英雄，敵対者，失われた愛，見つけた愛，そして幸福であり悲劇的でもある結果をもたらす偶然の事件をともなうのである．例えば Cumins社は，印象的なソフトウェアプロダクトラインの成功を達成するために，エンジン制御ソフトウェア，サポート技術，組織図，そしてプロセスを再構築する一方で，全ての製品の展開を6ヶ月間停止した．もしも，生産休止を延長した末に，予期せぬ事件によりプロジェクトが失敗に終わっていたとしたら，結果を想像してごらんなさい．
HM
Linda M. Northrop
IEEE Software, Vol. 19, No. 4, pp.32-40, July/August 2002
ソフトウェアプロダクトラインは，実行可能で重要なソフトウェア開発パラダイムとして，急速に立ち上がりつつある．SEI(Software Engineering Institute)は，その基本概念と，成功を保証する活動と実践を定義する．著者は，この手法を定義し，適用する間に学んだ， how-to，成功談，教訓について述べる．
HM
Frank van der Linden
IEEE Software, Vol. 19, No. 4, pp.41-49, July/August 2002
過去7年間，欧州の複数の企業が，EUおよび地方自治体出資のプロダクトファミリー開発共同プロジェクトに参画してきた．パートナー数社との小さなEU出資のプロジェクトから，ITEAの枠組み内の中央政府出資による大規模プロジェクトにまで成長した．著者は，異なるプロジェクト間の関係，各プロジェクトの取り組んだテーマ，これまでの主な成果についてまとめる．
ESAPS: Engineering Software Architectures, Processes and Platforms for System-Families
Cafe: From Concept to Application in System-Family Engineering
ITEA: Information Technology for European Advancemen
HM
Klaus Schmid, Martin Verlage
IEEE Software, Vol. 19, No. 4, pp.50-57, July/August 2002
プロダクトライン開発に移行しようとする時，組織は多くの難しい決定に直面する．プロダクトラインを採用する最良の方法は何か？ いかに通常の製品開発の混乱を避けることができるか？ 採用したら，いかにプロダクトラインを展開するべきか？ ガイドとしてどの手法を使うべきか？ プロダクトラインの経済的利益を最適化するためには，採用の文脈を考慮し，これらの疑問に答える際にプロダクトラインのスコーピング手法を用いることが重要である．
HM
Kyo C. Kang, Jaejoon Lee, Patrick Donohoe
IEEE Software, Vol. 19, No. 4, pp.58-65, July/August 2002
プロダクトライン(PL)ソフトウェア工学は，ひとつひとつスクラッチから開発する替わりに，コア資産から製品群を開発する方向へと組織を導く新出のパラダイムである．要求仕様はPL資産開発に欠くことができない入力であるが，PL資産を開発するのにそれだけでは不十分である．どのフィーチャ(特性)を製品としてまとめるか，そのフィーチャをどのように顧客に提供するか，その商品は将来どのように発展するか，といったことに関する計画を含んだマーケティング/製品計画もまた，PL資産開発を駆動する．フィーチャ指向再利用手法(Feature-Oriented Reuse Method; FORM)は，PLの共通と変動を製品フィーチャの見地から分析・モデリングすることに注力し，その分析結果を用いてアーキテクチャとコンポーネントを開発する．本稿において著者らは，ホームインテグレーションシステムを例に，いかにFORMがPL開発を効率化するかを示す．
HM
Steffen Thiel, Andreas Hein
IEEE Software, Vol. 19, No. 4, pp.66-72, July/August 2002
自動車システムは，本来乗客の乗り心地，安全性，経済性，防犯性を高めるものである．しかし，実時間性能，安全性，信頼性といった要求に関連した多くの設計上の問題が管理可能になった一方，費用対効果と time-to-market は自動車業界にとってなお難題として残っている．プロダクトラインは，システム開発におけるコア資産の戦略的再利用を可能にするので，この課題に対する有望なアプローチである．しかし，プロダクトラインアプローチで大きなスコープの経済を得るためには，開発プロセスを通して系統だった計画と継続的な変動性の管理を行うことが必要である．本稿において著者らは，プロダクトラインにおける変動性の価値について論じ，Bosch社におけるいくつかの実事例研究から導き出した，変動性をモデル化して使用するためのアプローチについて述べる．
HM
Ari Jaaksi
IEEE Software, Vol. 19, No. 4, pp.73-80, July/August 2002
著者は，Nokia がモバイルブラウザ製品を開発・提供するために，いかにプロダクトラインを開始し，使用したかについて述べる．彼は，Nokia がいかに組織を微調整し，プロダクトラインアプローチを維持するために必要な運用を行ったか，詳細に説明する．本稿は，顧客，技術，組織，そしてプロセスについて論じ，プロダクトラインを開始し組織するためのルールを提案する．著者は，プロダクトラインは再利用あるいはプラットフォーム駆動ではなく，製品とアプリケーション駆動であるべきだと提案する．彼はまた，Nokia において直面した課題と犯した失敗について議論する．
HM
Terry Bollinger
IEEE Software, Vol. 19, No. 4, pp.90-91, July/August 2002
私は自分を考えさせてくれるものを読むのが好きだ．例えば私は最近，ソフトウェア工学とは2つの対立するテーマをマージする試みである，と提案する記事を読んだ．少し言い換えると，私は第1のテーマを完全性のしつけと呼びたい．第2のテーマは創造の自由である．
HM
Reidar Conradi, Alfonso Fuggetta
IEEE Software, Vol. 19, No. 4, pp.92-99, July/August 2002
ソフトウェアプロセス改善の適用にはいくつかの問題が存在する．著者らの経験によると，規律のある作業 vs 創造的な作業，生産者リスク vs 顧客満足という2つの矛盾が，ソフトウェアプロセス改善の取り組みとアプローチを特徴付ける．これらの展望に基づき，ソフトウェアプロセス改善推進の問題点を示すために，また可能な改善を議論するために，著者らは6つの論文を紹介する．ソフトウェアプロセス改善へのアプローチは，組織的，経済的，戦略的課題を考慮するよう，大きく拡張されなければならない．研究者らはまた，例えばソフトウェア工学と社会科学の手法を融合することによって，体系的実験的研究を行わなければならない．
HM
Jose Pablo Zagal, Raul Santelices Ahues, Miguel Nussbaum Voehl
IEEE Software, Vol. 19, No. 4, pp.100-106, July/August 2002
全ソフトウェア開発プロセスの中で，保守作業が最も時間とリソースを要するものであることは意見の一致するところである．保守はソフトウェア開発の最終ステップであり，そして最も価値のないステップであるとみなされている．我々は，従来の見方を変え，実装ステージを保守と同様に考える，異なる視点を提案する．これは，ソフトウェア開発を次に保守が続く設計と捉えることを意味する．つまり，実装されるものを設計するのではなく，保守されるものを実装するのである．我々は，子供向け教育用テレビゲームの開発における経験を通して，この視点を示す．我々はこの例を用いて従来のプロセスと保守指向のプロセスを比較し，テレビゲームドメインにおける提案する手法の利点と欠点を明らかにする．我々は，特定分野向けCASEツール(SCASE; specific computer-aided software engineering)の概念を含んだ2つのツールを紹介し分析する．特に保守を考慮して設計されたツールが存在する．保守に向けた開発プロセスに注目するだけでなく，保守の重要性を考慮に入れることが，納期どおり予算どおりに成功を収めるソフトウェアプロジェクトの開発にとって大きな恵みとなると，我々は結論付ける．
HM
James A. Whittaker, Steven Atkin
IEEE Software, Vol. 19, No. 4, pp.108-115, July/August 2002
多くのソフトウェア工学関連の文献は，実践者が十分にやっていない，だから実情としては悪いソフトウェアを作っている，といった忠告で始まる．著者らはこの事実に反論しないが，ソフトウェア工学の文献が解として提供するものもまた十分でないと信じている．この問題に関する書籍は，プロジェクト管理，ソフトウェアプロセス改善，日程とコストの見積もり，といった分野の『明るい』側面だけを扱っている．ソフトウェアを開発するのに必要な本当の技術については，しばしば抽象的に記述されたり，明白なものと仮定されたり，全く無視されたりしている．しかし，ソフトウェア開発とは，どの管理方法を使っても部分的にしか効果がないような，根本的に技術の問題なのだ．それゆえに著者らは，実際のソフトウェア開発者が，しばしば非現実的な日程と予算の制約に逆らって，実際のソフトウェアを設計する前，設計している間，設計した後に用いる技術の基本セットについて述べる．
HM
Norman Fenton, Paul Krause, Martin Neil
IEEE Software, Vol. 19, No. 4, pp.116-122, July/August 2002
ソフトウェア計測には，製品開発のリスク管理において重要な役割を果たす可能性がある．予測モデルに組み込まれたメトリクスは，潜在リスクの進んだ警告を与えることができる．しかし，単純な回帰モデルを使う一般的なアプローチでは，特にソフトウェア障害を予測するためには，不適切なリスク管理の決定につながる可能性がある．ナイーブなモデルは，本当の因果関係を含んだ予測モデルで置き換えるべきである．著者らは，ベイジアンネットワークを用いてモデルを構築する方法を示す．それは，実プロジェクトの範囲におけるソフトウェア障害の正確な予測を与える，ソフトウェア品質リスク管理のための強力な図式モデリング手法である．ベイジアンネットワークは予測のために用いられるだけではなく，『〜としたらどうなるだろう？』というシナリオを実行して，潜在する問題と可能な改善活動を明らかにするために使われる．
HM
Robert David Cowan, Ali Mili, Hany Ammar, Alan McKendall, Jr., Lin Yang, Dapeng Chen, Terry Spencer
IEEE Software, Vol. 19, No. 4, pp.123-129, July/August 2002
ソフトウェア工学技術の進化を予測するとは，せいぜい疑わしい提案である．概して，それはがっかりするようなつまらない課題である．理由を知るのは難しくない．ソフトウェア技術の進化は速く，多くはソフトウェア工学の範疇外の目のくらむような数の要因によって決定されるからである．ほとんどの要因は，予測できないどころか，いかなる重要な事前通告としても特定することさえできない．本稿は，このドメインにおける著者らの最初の冒険と，いくつかの予備結論と提案について簡潔に論じる．
HM
IEEE Software (IEEE) Vol.19, No.5
Dorothy Graham
IEEE Software, Vol. 19, No. 5, pp. 15-17 , September/October 2002
評価のエキスパートであるDorothy Grahamは、テスターが要求の評価に関与すれば大いに時間と費用を節約することができると断言する。 もし要件に対して矛盾のない品質の基準があるならば、テスターは問題を提起し、コードがかかれる前に問題点を発見することができる。
HT
Thomas B. Hilburn, Watts S. Humphrey
IEEE Software, Vol. 19, No. 5, pp. 22-24 , September/October 2002
ソフトウェアの成長の影響と、社会のニーズを満たすという点で歴史的な実績の乏しさから、ソフトウェア工学のやり方は大幅な変更を必要としている。 ある試みはソフトウェアの専門家に彼らの職歴を準備させることに関係する：もし一貫して安全でセキュアで信頼性のあるシステムを提供したいと望むなら、その分野はソフトウェア工学の教育のやり方を徹底的に変化させなくてはならない。 本特集号は、大学の教育者、産業ベースの教育者の両方が、資格があり、能力があるソフトウェアの専門家に対する社会のニーズにより良く対応するために解決すべき問題点のいくつかを明らかにする。
HT
Richard Conn
IEEE Software, Vol. 19, No. 5, pp. 25-29 , September/October 2002
C-130Jのソフトウェア工場に対する教育のニーズは、企業、連邦航空局、国内、海外の軍隊や民間人の要件を扱う多くのソフトウェア開発領域をカバーするため、C-130J航空機それ自体の役割と同じくらい多様である。 この記事では、新卒雇用者と彼らの会社の間の期待の不整合を生じさせる原因となっている、コンピュータサイエンスおよび工学分野における従来の学術的な大学教育に不足しているものに焦点をあてることで、C-130J航空電子工学／ソフトウェア統合製品チームのソフトウェア技術者の教育と訓練への様々なニーズに対する見識を示す。 著者はチームで働くこと、話しあうこと、しっかりとした、規則的な、成熟した工学プロセスの重要性を理解することを，学生達に準備させることの必要性を指摘する。
HT
Jorge Diaz-Herrera, Mike Murphy, Dawn Ramsey
IEEE Software, Vol. 19, No. 5, pp. 30-34 , September/October 2002
この記事はある革新的な再訓練計画に関するレポートである。 その再訓練計画は、ジョージア州マリエッタのロッキード・マーチン社（Lockheed Martin Aeronautics Company）の従来の領域から余剰の技術者をとり、サザン・ポリテクニック州立大学での講義と会社に戻っての実習の組み合わせを通じて再訓練することでソフトウェア技術者に育てるために策定された。 この記事では今までの成果や上記のような協力関係を考慮した他者への推薦のみならず、計画と実施のフェーズも取り扱う。 著者らは学習過程、その進化、どうすれはそのような教育をより効果的にできるかに関する課題についての見識を示す。
HT
Hossein Saiedian, Donald J. Bagert, Nancy R. Mead
IEEE Software, Vol. 19, No. 5, pp. 35-41 , September/October 2002
新しいソフトウェア工学の学習過程は人気はあるが、論議を呼んでいる。 そのような学位取得過程を提供することは、新たなソフトウェア工学の学習過程が産業的なソフトウェア開発の問題を扱うであろうと信じている人（新たな学習過程が何を提供すべきなのか、いつ提供されるのが適切なのかを正しく認識できていない）により、大げさに宣伝されている。 新たな学習過程は、だたプログラミングに関する産業訓練を提供する機会としてしか捉えていない（しかし、ソフトウェアの複雑さを理解できていない）多くの従来のコンピュータ学者により難解な批判と主観的な評価を受けてもいる。 いろいろな意味で、ソフトウェア工学の学習過程を取り巻く現在の状況は、1960年代と1970年代のコンピュータサイエンスを取り巻いていた状況に酷似している。 30年から40年前、電気工学と数学の教授陣はコンピュータサイエンスの学位取得過程が発展するのに抵抗したが、現在はコンピュータサイエンスの教授陣がしばしばソフトウェア工学を同様の態度で扱っている。 この記事では新たなソフトウェア工学の学習過程を導入する現実の理解されている目的について、最も一般的に信じられている迷信（好意的なもの否定的なものの両方）のいくつかを明らかにし取り組む。 上記の学位取得過程の導入を計画している人は、これらの迷信に基づいて決断する代わりに、事実を理解すべきである。
HT
Jurgen Borstler, David Carrington, Gregory W. Hislop, Susan Lisack, Keith Olson, Laurie Williams
IEEE Software, Vol. 19, No. 5, pp. 42-48 , September/October 2002
この記事では、様々な文脈におけるソフトウェア工学の概念を教えるためにパーソナル・ソフトウェア・プロセス（Personal Software Process：PSP）を使用した５つの大学の経験を述べる。 また、大学のカリキュラムの中にPSPを導入するための提案とテクニックも記載されている。 この記事の目的は自分のソフトウェア工学の講座にPSPを導入しようと考えているかもしれない他の大学教師を勇気づけ、指導することである。 加えて、我々の経験は社内の教育プログラムへのPSPの導入を考えている企業にも適しているだろう。
HT
Ken Surendran, Helen Hays, Andrew Macfarlane
IEEE Software, Vol. 19, No. 5, pp. 49-56 , September/October 2002
いくつかの職業ではある個人を適正なメンバーと認める前に、インターンシップや研修医、見習いの期間を義務付けているが、ソフトウェア工学ではそれを行っていない。 大学はソフトウェア工学のカリキュラムを提供し始めたが、多くはコンピュータサイエンスのカリキュラム内の一部でソフトウェア工学の講義を提供し続けている。 ソフトウェア技術者に対する世の中の需要はソフトウェア工学の卒業生の供給量をはるかに上回っているため、コンピュータサイエンスや応用コンピュータサイエンスの卒業生がたびたびこのギャップを埋めることになる。 したがって、コンピュータサイエンスや応用コンピュータサイエンスのカリキュラムの中で、ソフトウェア工学の概念や原理を訓練する機会をもうけることによって、ソフトウェア工学の講義を強化するために、我々はシステム開発プロジェクトのシミュレーションを通じたソフトウェア工学の見習い制度を支持する。 この記事では、著者らはまずソフトウェア工学の専門家を育成するための知識領域から構成されるモデルを構築するために、一般的なソフトウェア工学の一連の知識やソフトウェア工学教育の全体像を調査する。 彼らは見習い制度が最も適した知識領域の輪郭を描くために、このモデルとブルーム（Bloom）の分類学を用いる。 そして、ソフトウェア工学の見習い制度のための枠組みを確立し、それをコンピュータサイエンス、応用コンピュータサイエンス、コンピュータシステムのカリキュラムを提供している別々の３つの大学で、見習い制度のシミュレーション実施の検証のために用いる。 さらに見習い制度を補うために、著者らは同等の組織的インターン制度や協同組合制度の使用を提案する。
HT
Dale Callahan, Bob Pedigo
IEEE Software, Vol. 19, No. 5, pp. 57-62 , September/October 2002
大学と産業界は学生が学校で何を学ぶべきか、仕事で何を学ぶべきかについて意見が一致していない。 ITにおいては、絶え間ない技術の変化や戦略資産情報の重要性の増加が問題を複雑にしている。 CIO(最高情報責任者/IT担当役員)やIT管理者は情報システムを考慮した戦略的なビジネスの意思決定をするためのスキルや知識だけでなく、情報システムの込み入った事柄を理解するためにしっかりした技術的なスキルを身に付けていなければならない。 このニーズを扱うために、アラバマ大学バーミンガム校は電気工学とコンピュータ工学の大学院専攻を開設した。 アラバマ大学は、経営幹部が学問的な基礎を損なうことなく業界のニーズを扱うカリキュラムを作成するのを手助けするために，彼らに意見を求めた。
HT
Grant A. Cheston, Jean-Paul Tremblay
IEEE Software, Vol. 19, No. 5, pp. 64-71 , September/October 2002
この記事ではコンピュータ学部学生のための入門コースについて述べている。 このコースはデータ構造とソフトウェア工学を統合することを目的としている。 学生にはいくつかの関連する分析、モデリング、ソフトウェア設計を含んだ多様な課題の達成に加えて、重要なソフトウェア設計プロジェクトチームで働くことが要求される。 学生がこのプロジェクトを達成するのを助けるために、オブジェクト指向ソフトウェアシステムを開発するための１０段階のプロセスを用いる。 著者らはそのようなコースを与えることの考え方、教えるコンセプトについて議論する。
HT
Thomas B. Hilburn, Watts S. Humphrey
IEEE Software, Vol. 19, No. 5, pp. 72-77 , September/October 2002
チームでのソフトウェアプロジェクトの効果は多くの問題に左右される。課題、市場、開発技術、会社の環境、チームメンバの能力、そしてソフトウェア開発プロセスである。 ほとんどではないにしても、多くの人は，人とプロセスの問題が、用いられた技術よりもプロジェクトの成功にとってより重要であると考えている。 この記事では学部の学生、大学院の学生にいかにソフトウェアプロジェクトチームで効果的に働くかを教えるための方法、テクニックについて議論する。 チームソフトウェアプロセス（TSPi）が開発され、学生のチームに効果的なチームワーク法を教えるためのコースが作られた。 このプロセスを用いた経験が議論され、チームの実績が紹介、分析される。 この記事ではTSPiコースを指導するための様々なモデルを記述し、そのようなコースを構築、指導するための提案を行う。 結論では、コンピュータのカリキュラムの中でTSPiを使う利益を要約し、産業ソフトウェアエンジニアとして働く学生を育成する中でのTSPiの役割を議論する。
HT
David Umphress, T. Dean Hendrix, James H. Cross
IEEE Software, Vol. 19, No. 5, pp. 78-85 , September/October 2002
大規模な学生のプロジェクトでのプロセス指向の観点は、エンド・ツー・エンドのライフサイクル技術を統合する際に学生を導き、プロジェクトの中で経験の一貫性を提供する。 49のcapstone projectsの指導を経て、著者らはプロセスの文化を養わなければならないことに気が付いた。それは、アジャイルプロセスがアドホックなコースのプログラミング課題と組織化されたプロジェクトワークの掛け橋となること、また、プロセスがツールとプロセスの専門知識に適切な基盤を要し、それらは学習に焦点をあてて構築されるべきであるということである．
HT
Lisa J. Burnell, John W. Priest, John R. Durrett
IEEE Software, Vol. 19, No. 5, pp. 86-93 , September/October 2002
実際の経験に基づいて、我々は産業界に見られるような分散され、多くの専門分野にわたる環境におけるソフトウェア開発のための革新的な教育手法を紹介する。 このケーススタディでは複数の学科、大学からの学生で構成されたチームにより開発されるプロジェクトについて述べている。 そして、使用したプロセスや得た教訓について報告する。
HT
IEEE Software (IEEE) Vol.19, No.6
活動を休止しておりました．
リコー
AbstractClub