▲ll∫■
■■
l

汀
︺

也
′

NewsIe憤erfromSoftwareEnglneerSAsSOCiation

Ⅶ1．14，N。mbe，5Jan。ary，2005

目

次
1

編集部から

2

石川雅彦

いくつかの国際会議報告

岸田孝一
1

SD2005参加者募集

4

SS2005論文募集

5

つ J

5

′ b

n フ

ProceedingsfbrlstJointWorkshoponEmbeddedSoftware

7

SEA名古屋，月見ミーティングレポート

0 ノ筏井美枝子ほか

4

インターネット時代のソフトウェア開発

SEAForumJanuary参加者募集

ソフトウェア技術者協会
SoftwareEngineersAsociation

ソフトウェア技術者協会（SEA）は，ソフトウェアハウス，コンピュータメーカ，計算センタ，エンドユーザ，大学，研究所など，それぞれ異なった環境に置かれているソフトウェア技術者または研究者が，そうした社会組織の壁を越えて，各自の経験や技術を自由に交流しあうための「場」として，1985年12月に設立されました．
その主な活動は，機関誌SEAMAILの発行，支部および研究分科会の運営，セミナー／ワークショップ／シンポジウムなどのイ

ベントの開催，および内外の関係諸団体との交流です．発足当初約200人にすぎなかった会員数もその後増加し，現在，北は北海
道から南は沖縄まで，400余名を越えるメンバーを擁するにいたりました．法人賛助会員も20社を数えます．支部は，東京以外に，関西，横浜，名古屋，九州，広島，東北の各地区で設立されており，その他の地域でも設立準備をしています．分科会は，東京，関西，名古屋で，それぞれいくつかが活動しており，その他の支部でも，月例会やフォーラムが定期的に開催されています．
「現在のソフトウェア界における最大の課選は，技術移転の促進である」といわれています．これまでわが国には，そのための適切な社会的メカニズムが欠けていたように思われます．sEAは，そうした欠落を補うべく，これからますます活発な活動を展開して行きたいと考えています．いままで日本にはなかったこの新しいプロフェッショナル・ソサイエティの発展のために，ぜひとも，あなたのお力を貸してください．

代表幹事： 荒木啓二郎
常任幹事：

熊谷章

高橋光裕

幹事：

石川雅彦 大場充 落水清一郎 窪田芳夫 小林修 小林允 桜井麻里
洒匂寛 塩谷和乾 篠崎直二郎 新谷勝利 新森昭宏 杉田義明
中来田秀樹 奈良隆正野中曹 野村行憲 野呂昌満 祐山投
平尾一括

田中一夫

深瀬弘恭

玉井哲雄中野秀男

藤野誠治

松原友美

渡遣雄一

事務局長： 岸田孝一

会計監事： 横本勝 書相成弘分科会世話人

環境分科会（SIGENV）：塩谷和範

田中債一郎

渡遵雄一

教育分科会（SIGEDU）：君島活 篠崎直二郎 杉田義明
ネットワーク分科会（SIGNET）：人見庸 松本理恵

中園順三

プロセス分科会（SEA−SPIN））：伊藤昌夫 塩谷和範 新谷勝利 高橋光裕 田中一夫 簿山投 藤野誠治
フォーマルメソッド分科会（SIGFM）：荒木啓二郎 伊藤昌夫 熊谷章 佐原伸 張漢明 山崎利治
オープンソース分科会（SIGOSS）：石川雅彦 岸田孝一 杉田義明 鈴木裕倍 中野秀男

支部世話人 関西支部：

小林修 中野秀男 横山博司

横浜支部： 野中菅 藤野晃延 北條正顕
名古屋支部 ：石川雅彦 角谷裕司 野呂昌清

九州支部： 荒木啓二郎 武田淳男 平尾一浩
広島支部： 大場充 佐藤康臣 谷純一郎
東北支部： 布川博士 野村行憲
賛助会員会社：ジェーエムエーシステムズ
オムロンソフトウェア

ダイキン工業
リコー

オムロン

NTrデータ

SRA西日本SRA PFU

キヤノン

音士電機

ヤマハ

テブコシステムズ

盲士通

新日鉄ソリューションズ

ブラザー工業

オープンテクノロジーズ

日本総合研究所

SRA東北

エフビクス

（以上20社）

SEAMAIL Vol．14，No．5

2005年1月15日発行

編集人岸田孝一

発行人ソフトウェア技術者協会（SEA）〒160−0004

東京都新宿区四谷3−12

T：03−3356−1077F‥03−3356−1072

印刷所市田印刷株式会社

定価

丸正ビル5F

E−mai1：Sea＠sea・Orjp URL：http：〟www・SeaJp〒114−0014

500円（禁無断転載）

東京都北区田端2−3−25

MessagefromEditor

SeamailⅥ）1．14，No．5

編集部から

☆

半年ぶり，例によって船便のSEAMAILです．

☆☆
この号の巻頭には，SEA名古屋支部からのミーティング・レポート2篤を載せました．報告をまとめてくださった筏井さん，石川さん，ありがとうございました．

☆☆☆

その他の支部や分科会も，それぞれ活発に活動されているようですが，その内容をぜひここで報告していただけると輯しいです．
☆☆☆☆

原稿不足を補うために，編集責任者として，この夏以降自分が参加した国際会譲やミーティングの報告をまとめてみました．何かの参考にしていただければ幸いです．
☆☆☆☆☆
この報告のなかでも触れましたが，11月に西安で開催されたISFST2004のPost−SymposiumProceedings

が，プログラム委員長の塩谷さんの手でまとましましたので，この号に挟み込んでお届けします．
☆☆☆☆☆☆
最後に載せた英文のWorkshopRepor日は，昨年の秋に韓国・ソウルで開かれた組み込みワークショップの記録（参加された方々のPositionStatementと3つのグループ討論のまとめ）です．

☆☆☆☆☆☆☆
岸田孝一＠SEAO用ce

MeetingReport

SEAMAILVol．14，No．5

インターネット時代のソフトウェア開発
SEA名古屋支部ミニセミナー報告
記録担当：筏井

美枝子

5月21日（金）に、名古屋市鶴舞の＜つながれっと名古屋＞セミナールームで、「インターネット時代のソフトウェア開発」をテーマに月例のミニセミナーが開催されました。

今回はパネルディスカッションということで、中野秀男（大阪市立大学）先生、岸田孝一（SRA・mL）さん、田中一夫（日本フイツツ）さんのお三方をパネリストにお迎えし、中野先生からはインフラ・メディア技術からの視点で、岸田さんからは社会学・認知科学的な視点で、田中さんからはプロジェクト管理に基づく開発現場からの視点で、それぞれ、インターネット時代のソフトウェア開発を語っていただき、それらの多角的な視点をもとに、参加者全員でディスカッションをしました。

まず最初に、中野先生から、今日のパネルプレゼンテーションの一部を録画したものをイ
ンターネットを介して、動画として見せていただきました。目の前の中野先生に紹介されて、インターネットの向こうの双子の中野先生がプレゼンしているようなおかしな感じで、会場が思わず笑いに包まれました。中野先生からは、ネットワークが格段に早くなったことで・どこでも仕事のできる環境になったことや、動画系の様々な技術が普及し、リアル

タイム中継や電子会議など多方面への利用が進んでいることなどを、実際にデモをしながらご説明いただき、先端技術が利用技術になるまでの期間がどんどん短くなっていることを、参加者一同実感しました。
続いて、岸田さんからは、様々な文化的・歴史的背景を持つ人間集団の活動を研究するための概念的枠組みとして「ActivityTheoryJの紹介がありました。この理論は、そもそもは、1920年代にソビエトの教育心理学で提起されたものが、1980年代になって社会学・経営学に応用され西欧からアメリカに普及し、1990年代になって、CSCWやCHIの世界で話題になったきたのだそうです。さらに、岸田さんからCSCWMagagineに掲載された興味深い論文が二つ紹介されました。一つは、J・Engestromによるもので、人間集団の活動を分析するツールとして・ActivityTheoryに基づく三角形のフレームワークを提示した論文です。岸田さんは「このフレームワークの最大の欠点は、このフレームワークで分析したからといって、何がどう役にたつのかわからないことです」と愉快そうに付け加えましたoもう一つは、B・Nardi、S・Whittaker・H・Schwartzによるもので、人間同士のプライ

2

SEAMAILVol．14，No．5

MeetingReport

ベートかつ悉意的なネットワークをNetWORKと定義し、NetWORKはダイナミックかつ複雑に様相が変化するのでフォーマルなダイアグラムに表しにくいとしながらも、ヒューマンインターフェースやCSCWにとっての重要性を強く示唆した論文です。
最後は、田中さんから「でも、変わらないプロジェクト・マネージメント」という副題で、ソフトウェア開発現場の経験談をおりまぜながら、インターネット時代になっても、プロ
ジェクト・マネージメントの世界は相変わらずスマートに行かないというお話しをしていただきました。たとえば、見積もりの誤りや、仕様が丘Ⅹしないことが今も昔もプロジェ

クトの失敗の大きな原因であること、システムは大規模・複雑化しているが、納期は短くなる一方であること等があげられました。また、プロジェクト・マネージメントに役立つもので、ツールとしてMS・PrQjectやⅩDTS、教科書としてPMBOK、環境としては仕事場の共有、Daylymeetingの実施、PMOなどが紹介されました。特に、田中さんお薦めの課

題管理ツールⅩDTS（ニルソフト）は実データを使ったデモによる紹介があり、参加者から高い関心が寄せられました。

インフラやメディアの技術が充実・高度化する中、インターネットの利用はすごいスピー
ドで広がっています。その利用法も、よりダイナミックに、より複雑なものとなり、人間同士のコミュニケーションや仕事のスタイルも劇的に変化してきています。一方で、それらがダイナミックで複雑になればなるほど、仕事の管理（状態の把握やコントロール）はより一層難しくなり、以前の管理方法では立ち行かなくなってくるのは明らかです。ソフ
トウェア開発の世界も例外ではないはずなのですが、プロジェクト・マネージメントの世界にはさしたる変化がないとの発表に、時代の変化速度とのギャップが感じられました。
管理技術が時代の変化にまだ追いついていないためなのか、はたまた、マネージメントそのものの特性／限界なのか？

26名の参加者による和やかなパネルディスカッションは、場の盛り上がりをそのままに懇親会へと流れこみ、パネリストを囲んでにぎやかに遅くまで続いたのでした。

3

MeetingReport

SEAMAILVol．14，Ⅵ）．5

SEA名古屋、月見ミーティング

レポート

石川雅彦
（SRA）

2004年10月27日（水）は名古屋の天気は快晴で、ほぼ完全な満月が見られました。

この日に合わせて、SEA名古屋のオフラインミーティングを開催しました。
参加対象は、buiと呼ばれる、企画運営委員です。なぜkiuiと呼ばれるかというと、KIkakuUn・eiIin

から適当に略してつけたからです。kiuiは、

社会人ソフトウェア技術者向けミニセミナーの常連を中心に、1996年くらいから企画運営を続けています。活動から8年もたつとさすがに、kiuiスタッフのポジションや関心も変わります。kiuiスタッフの関心を中心に単独主催セミナーを2・3か月に一度開催するのが従来のスタイルでしたが、2004年の活動を振り返ると単独開催は1回のみ。後は他組織のイベントに共催するという状況でした（表1）。また、一昨年、昨年と開催した夏の合宿は今

年は開催なしでした。そこで、ひさしぶりに集まって近況を連絡しあうと共に、今どのよ
うなことに関心があるか、その関心を基にこれからどのようなことをしていきたいか話し合うことになりました。
表1：SEA名古屋2004年のアクティビティを書き出してみた

・第4回オープンソースセミナー共催（1月）
これでいいのかインターネット〜spamとプライバシーの観点から〜

・第5回オープンソースセミナー共催（5月）
オープンソースを活用した、組み込みマイコン開発
・第6回オープンソースセミナー共催（9月）「オープンソース三つ巴」「LinuxZaurus／PDA事情」

・第7回オープンソースセミナー共催（10月）「オープンプリンティング」
・第8回オープンソースセミナー共催（11月）「SH・Linuxカーネルのリアルタイム割込み」

・GWのKIUIミーティング

・SEA単独主催セミナー（5月）タイトル：

インターネット時代のソフトウェア開発

パネラー：岸田孝一（SRA−ⅨTL）、中野秀男（大阪市立大学）、田中一夫（日本フイツツ）

開催場所は名古屋市内本山周辺と決めました。本山は地下鉄東山線の駅でしたが、地下鉄

4

MeetingReport

SEAMAILVol．14，Ⅵ）．5

名城線の乗り換え駅になりました。
地下鉄名城線は従来、大曽根から南下し、金山駅で名古屋港行きと新端橋（あらたまばし）行きに分岐していました。10月？日から新端橋〜八事〜本山〜大曽根とつながって環状線になりました。金山〜名古屋港は名古屋港線と名称が変わり、おたまじゃくしのしっばのように丸い名城線に接続するようになりました。開通間もないうちに、新環状線に乗りた
い、というのが場所選定動機となりました。
会場は、1階窓際で月が見えることが条件で選定。本山から山手通りを名古屋大学の方に上っていくと、ちょうど月を左にながめながら移動することができます。上り坂の途中で見つけたお店をのぞくと運良く1階窓際が空いていました。
集合時刻は18：00ということもあり、参加者はぽつぽつと集まってきました。参加表明は7名でしたが、1名が仕事都合で欠席。他6名全員が、19：00過ぎには揃いました。

ひさしぶりのオフ会ということもあり、最初は近況や雑談で始まりました。が、あまりにローカルなので割愛します。ここでは、SEAMAlLにふさわしいと思える話題のみを抽出して取り上げます。

民芸品のようなソフトウェア
工業製品ではなく工芸品のような、あるいは民芸品のようなソフトウェアをつくりたい、という話題が出ました。民芸品のようなとは具体的に何かは明確ではありませんが、大量生産を指向しないもの、規格を統一することは必ずしも要求されず、むしろある範囲のばらつきに価値があると解釈することもできます。
民芸品の例として「さるばば」が挙がりました。（現在のさるばばが民芸品であるかについては異論も出ました。）
またミーティング後の情報交換で、私たちと同年代のソフトウェア技術者が、「業界で最後の竹細工職人を目指している」という発言を引用し、異なる場所で同じ方向を目指す人がいることをうかがわせました。
同じく、ミーティング後の情報交換で「民芸」ということばは、柳宗悦や浜田庄司、バーナードリーチといった人たちが、提唱したものだという指摘があり、指摘者の解釈によれば、・民芸品とは、人間の日常の中で丁寧に作られ、しかも高い芸術性をもつが、奮った芸術ではなく、民衆の生活の中に溶け込み、時代を超えて、つつましく粛々と伝えられてきたものだとのことでした。

浦河べてるの家

5

MeetingReport

SEAMAILVol．14，Vo．5

この話は、kiuiスタッフの興味の方向が、テクニカルやオペレーショナルな面だけでな

く、社会や福祉の方向に向かっていることを示すトピックとして挙げます。
この話題の後、関心を持ったスタッフが情報源を調査し、提供しました。
www．tOkeidai．co．jp／beterunOie／
www．jinken．ne．jp／challenged／beteru／

http：〟6104．teacup．com几etheln）bs
WWW．yOmiuri，CO．jp／iryou／renai／20040727srll．htm

http：／／www．amazon．co．jp／exec／obidos／ASIN／4260332104／250・4925998−0508212

またこれに関して「べてるの家の「非」援助論」という本はお勧め、という意見が出ていました。話は更に、2003年の夏にSEA名古屋で講師をした、ITステップの山口つかさ氏

が、視覚障害者のためのITのボランティアをしているという話も掘り起こされました。
関西オープンソース2004参加の感想

2004年10月22日（金）23日（土）にかけて、関西オープンソース2004が開催されました。
（http：／k・0￡jp／）kiuiスタッフのうち、自主参加が2名いましたが、示し合わせてもいな

いのに、会場で偶然出会った話が披露されました。一人の方は、情報家電の講演が印象的だったと発言していました。
今後のアクティビティについて
kiuiは仕事とは違う集まりですが、そのような集まりは鼓舞されたり触発される機会が大事だという感想を抱くミーティングでした。
日常の活動はお互いに忙しく、接点がありませんが、背景の違いを前提にして、意見や情報を交換する場が必要だと感じられました。それは、2−3時間のオフ会ではとても語りつくせないように思われました。

これは今回の参加者に共通するものがあったようです。場所をあらためて時間をとって話す機会を計画することになりました。

場も人も異なる状況に身を置くことで、自分の考えに新たな発見が期待できるように思います。一言で言えば「ワークショップ」となるでしょうか。kiuiスタッフ、あるいはもう少し範囲を広げたワークショップを企画することで今回のミーティングの結論となりました。

6

SEAMAILVol．14，No．5

MeetingReport

いくつかの国際会議の報告
岸田孝一（SRA・mL）

なんとなくあわただしかった2004年も終わろうとしている．あらかじめかなり覚悟はしていたのだが，予想通り（というか予想以上に）忙しい思いをさせられた・あらためてカレンダー
を振りかえって見ると，夏以降の海外出張は次の通り：
7／6・12（上海）DyncPrQjectMeeting

8／9・15（フフホト）

ISFST2004PCMeeting

10／13・16（上海）：

Pre・ICSEInternationalWorkshop

10／19・25（西安）：ISFST2004

10／31・11／5（NewportBeach：）

FSE2004

11／29−12／4（釜山）：APSEC2004

この間にSEA，JASPIC，SMSG，Dyncなどの国内ミーティングがいくつかはさまっていたので，いそがしかったわけだ．11／22・28には毎年友人たちと東京・京橋の画廊で開いている絵のグループ展もあった。

以下に，それぞれの海外ミーティングの簡単な報告をまとめておく・

1．PrqjeetMee血g（7／6−12，上海）

Dync（DynamicCommumity）というのは，文部科学省からの補助金をもらって昨年の秋から

SRA・KTLが，阪大（井上研究室）・MST（松本研究室）・東大（中小路研究室）と一緒に進めている研究プロジェクトである．その内容については今年のSS2004Proceedingsに採録されている論文「知識共創のためのダイナミック・コミュニティ：理論・アーキテクチャ・応用」（彙・山本・岸田）を参照されたい．
関連した研究を行っている内外の研究者との交流を目的として，シンポジウム形式の会合を積極的に開いている．昨年の12月にはUCIrvine，今年の1月には函館未来大学とのJoint

Workshopを開催した．今回の上海ミーティングは，プロジェクトの発案者である菓雲文（協Yunwen）さんが母校である復旦大学をお借りして，同大学および華東師範大学・華東理工大学の研究者，そして上海在住のSEA会員である鐘友良さん（HypersoftShanghai）を招いて1日のワークショップを開催し，そのあと1日はプロジェクト内部の技術ミーティングを行った・

いま中国では中央政府のお声がかりでIT産業振興を目的としたソフトウェア技術者の養成が進められており，全国32の拠点校に軟件学院（ソフトウェア専攻科）が開設されている・復旦大学軟件学院の所長は，むかし葉さんのクラスメートだった威斌宇（ZangBinyu）さんである・コ

7

MeetingReport

SEAMAILVol．14，No．5

ンパイラ作りや並列処理の専門家，大学を出たあと，上海にある米国メーカの研究所で仕事をしていたが，学長命令で大学に呼び戻された．以前一緒に食事をしたとき，「上からはブルーカラーのソフト技術者をたくさん育てろといわれているのだけれど，大いに疑問に思っている」といわれたので，「その通り，中国のソフトウェア産業を振興するためには100人のブルーカラー
ではなく少数のスーパー・プログラマを育てることが大切ではないか」とアドバイスしておいた．

今回かれは会議出張で上海を留守にしていたので会えなかったが，菓さんの話では，復且の軟件学院は他の大学とは異なる教育方針で少数精鋭を目指しているとのこと．何年かあとの成果に期待したい．

2．ISFST2004PCMee血g（8／9−15（フフホト）

昨年のSARS騒ぎのため1年順延になったISFST、PCMeetingも昨年予定していた内モン
ゴル自治区の首都フフホトでの開催となった．この街には，1999年のPCMeetingin太原の後に訪問したことがある．5年前と比べて街の風貌はかなり変っていた．いくつもの高層ビルが立ち並び，さらに新しいオフィスビルやショッピングセンターが建てられつつある．
PC会場のホテルは金歳大酒店（Jin・SuiHotel）という名前なのだが，裏手に市の税務署のビルが隣接していた．訊いてみると，このホテルは税務署の経営なのだという．金歳の「歳」は中国語では「税」と同じ発音だそうだ．いうなればGoldenTaxHotel！？

PCメンバーの1人松原友夫さんの奥様が戦時中にお隣（といっても100KM以上離れた山西省・大同市に住んでおられたとかで，車をチャーターして日帰りで当時住んでおられた場所を見に行かれたのだが，ホテルに頼んでやってきた車は地元警察の公用車，ドライバーは制服姿の若いオマワリさん．途中渋滞した高速道路をサイレンを鳴らしながら突っ走ったそうだ．警察がそんなアルバイトをしてもよいのだろうか．「何でもありの国ですね」というのが松原婦人の感想．
昔の家は取り壊されてそこに学校が建っていたけれど，街のたたずまいは昔と変らなかったとのこと．

1年の空白が影響したためか，今年は中国以外からの論文応募がやや少なかった．中国からの論文も以前より質が落ちたような感じがする．ここ数年，中国で開催される国際会議の数も増えてきたので，昔のようなISFSTの希少価値も失われつつあるようだ．そろそろモデル・チェン

ジを考えなければいけないと感じた．
PCが終わったあとバスで山越えをして訪ねた大草原は中国国内の観光ブームで大きく様変

わり．以前にはなかった観光用のパオ（ただしコンクリート製！）の団地が点在していて，昔の面影は失われてしまった．ただし，夜空の星と，大草原に上る朝日の景色は壮観．

3．Pre・ICSEInternationalWorkShop（10／13・16，上海）

みなさんご存知のようにICSE2006は上海での開催が決まっている．しかし，中国ではまだICSEの存在はそれほど知られていない．また，欧米の研究者たちの目からすると，中国におけるソフトウェア工学の研究・実践の状況がほとんどわからない．そこで，両者の相互理解を深め

8MeetingReport

SEAMAILⅥ）1．14，No．5

ICSE2006in上海を成功に導くために，今年そして来年にいくつかのPre−Eventを開催しようということが，GeneralChairのLee Osterweil先生とLocalArrangement担当のJu

Dehua（居徳華）先生の相談で決まった．

軟件工程国際合作研討会と名づけられた今回のワークショップはその第1弾である．上海市政府（ITを担当する部局である信息化委員会ShanghaiMunicipalInformationCommission）がスポンサーになり，欧米から合計10人の研究者を招いて3トラック併設2日間のワークショッ
プが開かれた．
InvitedSpeakersList（withpresentationtitle）は次の通り：（1）processⅡack
LeeOSterWeil：

PreciseProcesSDefinition

JackyEStubilier：Processes，Interoperability，andCoordination

RoSSJe鮎ry：

SoftwareProcessImprovement（2）TbstingandAnalysisTrack
MaryLouSoffa：
IJOriClarke：

IntegratingSystemEnvironmentsintoSoftwareTbsting

FiniteStateVbrificationapproachforSoftwareSystems

MaryJeanHal・rOld：

TbstingandMaintenanceofSoftware

TbstabilityandReliabilityofComponent−basedSoftware（3）Di8tributed，Component−basedSystemTrack
AlexWoは：Publish／SubscribeCommunicationforDistributedSystems
JeffKramer：

Model−basedDesignandAnalysisofConcurrentand
DistributedPrograms

CarloGhezzi：EvolutionofSoftwareCompositionMechamisms

一見してわかる通り，現在のソフトウェア工学の第一線を代表するメンバーである．これらの人たちの招碑費は全額上海市政府が負担した（中国の官はお金持ち！）．
会場の銀河賓館（GalaxyHotel）は，虹橋空港（いまは主に国内線に使われている古い飛行場）から市内へ向かう直線道路の終端にあるホテルで，泊まるのは今度が初めてだった．SARSの休業期間中に内装を取り替えたとかで，部屋は4つ星らしくきれいだった
ワークショップ前日の午後に，これからの中国におけるソフトウェア技術・産業を振興させるにはどうしたらよいかという主題のミーティングがあり，Ostwerweil，Soffa，Wolfの3先生とわたしがSpeakerに指名されていたので，チェックインもそこそこに会議室へ直行・朱三元さん（もと上海ソフトウェアセンター所長）ほか何人か旧知のひとたちの顔も見えた．
わたしはいつも引用しているスペインの哲学者オルテガの言葉を引き合いに出して自立した強い精神を持つエンジニアを育てることがまず必要だと話したのだが，いつもながら中国でのこうした会議では会場からの質問やコメントがあまり出ないので，どの程度こちらの意図が通じたかどうかはよくわからない．
翌日からのワークショップでは，ProcessTrackで3人の招待講演と何人かの中国側の発表をMeetingReport

SEAMAILⅥ）1．14，No．5

聴いた．
Osterweilさんの講演TreciseProcessDefimition

は，ひとことでいえば「プロセス・プロ

グラミングの現在」ともいうべき内容で，いまかれの所属するMassachusetts大学LASERグループ（hbforAdvanCedSoftwareEngineeringResearch）［＊］で開発しているモデル化言語

Little−JILとそのインタープリタLittle−JILを中心にした話だった．
［＊］http：／Aaser．cs．uma8S．edu／

技術的な詳細は2年前に東京（日大文理学部のシンポジウム）で聴いたのとほほ同じだが，ソフト開発以外の分野（e−コマースや医療）でのプロセス記述と分析のケース・スタディは耳新し
く興味深いものだった．

プロセス・プログラミングの思想的背景を説明したスライドの1枚にCMMについての評価が，次のような辛口のコトバで書いてあった：
TheCapabilityMatwityModel（CMM）i＄aSpecificApproachto

SoftwareProceSSImprovement

ItisatestplanforblackboxteStingofproceSS
Can一ttestqualityinto80ftwareprocessproducteither・

この点については会場からも質問があったが，08terWeilさんの意見は，「現在多くの企業がCMMにのめりこんでいるのは不幸な間違いだ」ということだった．

Software Proces層is

凱此ware，恥0日というのが，かれの基本的な考えなので，ソフトウェアとしてのプロセスの品

質をテストするには，CMMのようなマクロなブラックボックスのテスト計画を立てるだけでは無理で，プロセス支援技術やツールを考慮に入れたマイクロ・モデルを用いたホワイトボック
スのアプローチが必要だという指摘だと思われる．
現在の日本でも，METIの意向を反映してか，CMM支持者が多いように見えるが，いつか適当な機会に，SEA・SPINあるいはJASPICで，こうした批判的な意見を聴いてみるのもよいのでは，と感じた．
昼食休憩をはさんだ，午後のセッションではフランス・グルノーブル大学のJackyEstublier

さんのプレゼンがあった．SCM（ソフトウェア構成管理）のツールとして有名なAdeleシステ

ムと，その後継システムであるApelの開発や応用をベースに，プロセス研究の過去・現在・未来を展望した話で，Workflow，EAI，BPM，WebService，MDA仲丑DEなどの話題までを取り込んでうまくまとめてあるのに感心した．フランス的知性のなせる業だろうか．ちなみにAdeleグ
ループのWebPageは：httl）：／／www・adele．imag．fr／index en．html

かれが使ったスライドの1枚に：Beliefb（1）AproductcannotbebetterthanPrOCeSSbywhichitisproduced

CMM，RURetc（2）Acompanycanimproveitsproducts，itspTOductivity，andits

benentsoulybyimprovingitsprocess・

10

MeetingReport

SEAMAILⅥ）1．14，No．5

SPItrend（3）AprocessisuSefulonlyifexecutable

SoftwareProcessという3つの信条のリストがあった．つまり，プロセスをどうとらえるかは「信仰上の問題」（！）

なので，どれが正しいというのではなく，違いがあるということである．
かつて一連のISPW（国際プロセス・ワークショップ）に参加していた人たちの多くは（3）の立場だったと思う．ツール開発者である

Estubilier

さんもその1人．CMM発案者のHumphreyさんは少数派の（1）だった．
2日日朝の招待講演はオーストラリアのRossJe鮎ryさん．UniverSityofNewSouthWalesの先生なのだが，いまは政府の出資でできたNICTAという非営利組織でEmpiricalSoftware
EngineeringResearchProjectのリーグに指名され，いまはそちらがメインの仕事になっているらしい：http：／／nicta．com．au

産学協同でプロセス・モデルにもとづくソフトウェア開発環境の仕事を手がけているという．
具体的には，小規模（20〜30人規模）のソフトウェア企業におけるプロセス改善を実際にやっていて，そうした規模の組織では，ソフトウェア・プロセスだけを改善してもだめで，それと密接に結びついたビジネス・マネジメント・プロセスの改善を一緒にやらなければいけない．そのための支援環境を開発し，データの収集と分析をやっているという話は，かなり具体的で説得力があった．
CMMについてはやはり批判的で，会場からの質問に答えて，「CMMが提唱されたのは，もう10年以上も前のことなのに，それ以降ソフトウェア・コミュニティに対して，なんら見るべき技術的頁献をしていないというのは，いかがなものか」と述べていた．
Small＆MediumSizeの企業が多いオーストラリアの場合には，SPIとビジネス・マネジメ

ントの改善を一緒に扱えるシステムが必要だというのが，かれの主張．オーストラリアでは，その機能を持ったSoftwareMarkというシステムが広く使われているとのこと．Software

EngineeringAustralia（略称：SEA）という会社が提供しているようだが，詳細は不明・
http：／／www．seanational．com．au／index．jsp

他の2つのTrackを覗く余裕はなかったが，それぞれかなり充実した内容だったようだ．第一線のソフトウェア工学研究者の話がまとまって聴けるよい企画だと思ったので，あちこちにmailでPRしたのだが，結局，一般参加の聴衆は中国の人たちだけで，日本や韓国からの参加がなかったのはちょっと残念だった．
ICSE2006Pre−Eventの第2弾としては，すでに会員DMでもお知らせしたが，来年の5月
末，ICSE2005inSt．Louisが終わった次の週に，北京でSoftwareProcessに関する国際ワー
クショップが開催される．ProgramCo−Chairは，Osterweilさん，BarryBoehmさん，そして中国科学院・軟件研究所長の李明樹（LiMingshu）さんの3人．PCには阪大の井上先生，

NAISTの飯田先生，それにわたしも加わっている．日本からも多数の参加を期待したい．

11

MeetingReport

SEAMAILVol．14，No．5

4．ISFST2004（10／19−25、西安）

上海ワークショップを終えて一旦東京に帰り，週末から月曜日にかけて雑用を片付けてまた中国へという忙しい旅になった．
西安訪問は一昨年のISFSTのPre・SymposiumSeminar以来2年ぶり．街はさらに変貌していた．夜の空港に着いてタクシーで，市の郊外の大雁塔近くにあるホテルに向かった．玄莫三
蔵ゆかりのこの古塔は20年前，初めての中国旅行のときに来たことがあるのだが，かつては廃墟に近かった風景がきらびやかな観光地に変っていて，塔も美しくライトアップされているのに驚いた．街がきれいになったのはうれしいが，しかし，途中の高速道路の側壁を彩る三色のネオンライトも含めて，大雁塔周辺の公園のデザインやライティングの色彩感覚は，折角の古都の風

情を台無しにしているような感じで，あまりいただけない．
シンポジウムの主会場は8年前のISFST1996のときと同じ西北大学のサイエンス・ホール．

ここは以前と変っていないが，隣接するゲストハウスは新しくなっていて，パラレル・セッショ
ンにはそこの会議室が使われた．
1987年秋，上海でのシンポジウムから始まった中国での国際会議も今年でもう16回を数える．日中シンポジウム3回（1987−90，天安門事件で1回中止），国際CASEシンポジウム5回（1991−的）国連大学（UNU／ⅠIST）の協賛を得て現在のISFSTになってから8回（1996・2004，

SARSで一回中止）．PCMeetingの項で書いたように，そろそろ新機軸を考えるべき時期である．今回は，かつて北京（1991）およびアモイ（1997）の会議で試みて好評だったワーキング・グル

ープ討論のセッション3つを会議初日の午前中に組み入れて，若干のモード変更を図った．それ
ぞれ適当に盛り上がって成功だったと思う．

本会議オープニングの基調講演は，岡山のSS2004にもお招きした韓国POSTECHのK．C．Kang先生．テーマはもちろんProductLineSoftwareEngineering。これから何年かソフ

トウェア工学の中心的話題になるトピックだが，まだまだ研究先行で産業界における実践が遅れているのが現状だと思う．いま，Kang先生が韓国や日本で進めておられる応用がうまくショー

ケースとして使えるような結果を生み出すことが望まれる
午後からの本会議は3つの並列トラックに分かれての論文発表．ここ数年，論文が採択されているのにかかわらず，会議にはやってこない不心得者の数がふえてきた．アカデミック・ポイン
トを稼ぐためには，論文がProceedingsに載りさえすればよいと考える若い学生や研究者が多くなったらしい．こうした傾向は全世界共通のようで中国もその例に漏れない．ISFSTでは，そうしたNo−Showを防ぐために，前回から会議開催前にProceedingsを印刷することを止め，実際に会議で発表された論文だけを収録したPost−SymposiumProceedingSをCD媒体で作ることにした．
今回の会議のProceedingsCDは，このSEAMAILに同封されているので，発表論文の詳細については，そのCDをご覧いただきたい‥
SEAが主催する会議は，ISFST

もそうだし，国内のSSそのほかの会議もそうだが，Proceedingsに論文を載せるのが目的ではなく，会議の場での論文発表とそれをきっかけとする

12

SEAMAILVol．14，No．5

MeetingReport

討論や交流を目的としている点が通常のアカデミック・コンファレンスとは異なるのだが，そのぁたりの事情はなかなか一般には理解されず，論文集めやプログラム編成には苦労が多い・
来年のISFSTは，ICSE2006のPre・Eventの1つとして，上海での開催が予定されている・

このへんで普通の国際会議とは一味違う特徴をだすために，論文発表を少なくして），いくつかのホットトピックについてのグループ討論を主体にした形に変えるのも一案ではないかと考えているのだが，どうだろうか．これまでの経験からすると，中国の人たちは（韓国の人たちも）そうしたワークショップ形式の会議はまだ慣れていないような感じがするが，思い切って試みて

みたい．日本でも，1980年代の初めにSEAの前身である旧ソフト協技術委員会がワークショ
ップ・スタイルの合宿会議をはじめたときには，「なんで技術問題を討論するのに田舎のホテルや温泉に泊り込みで行く必要があるの？まさか遊びじゃないだろうね？」と・怪訝な顔をされたものだった．
西安での会議が終わったあと北京へ飛んで，病気療養中の鐘錫昌（ZhongXichang）先生を見舞った．教えられた301病院に行ってみると，正式名称は人民解放軍総医院・あとできいたら，中央政府で2番目に偉いランクの人がはいるところだそうだ・科学院ソフト工学センター所長というのはそうした地位なのだとあらためて感心した・

軍服姿の兵隊さんの門衛に特別治療病棟の場所を教えてもらい，広い敷地の中まで歩く・建物の受付デスクにもやはり兵隊さん・来意を告げ，教えられた階段を上がって行くと，受付から連絡があったのだろう，奥様が廊下の外れまで迎えに出て来られていた・点滴の管はつけていたが，鐘先生は元気そうな様子だった．ちょうどアメリカ（ニューヨーク州立大）に留学中のお嬢さんと電話がかかっていたところだったので，東京で顔見知りだったお嬢さんともひさしぶりに日本
語・英語とりまぜてお話しした．
去年の秋，中野先生が大阪で開かれているオープンソース・ソフトウェアのイベントに鐘先生をご招待して，本人も来る積りになっていたところへドクター・ストップ・それ以来ずっと入院生活だから，もう1年になる．科学院のオフィスの隣にあったアパートが道路拡張で取り壊されることになったので新しくアパートを買ったのだが，まだそこに足を踏み入れていないのだと苦笑されていた．治療の経過がよさそうなので，「来年には退院できるでしょう・お元気で」と別れを告げた．

5．FSE2004（10／31−11／5、NewportBea血：）FoundationofSoftwareEngineeringと名づけられたこの会議はACM／SIGSOFTの年次大会で，偶数年は11月にアメリカで，奇数年はESECとジョイントで9月にヨーロッパで開催されることになっている．3年前の9月，ウィーンでの会議は，会議初日が9／11のテロにぶつかって大騒ぎ，レセプションをそこそこに切り上げてホテルに帰り，BBCとCNNを交互に切り替えながらTVを観ていたことを思い出す・
Foundationというネーミングを見て，最初はさまざまな方法論の思想的「基礎」を議論する

会議なのかと考えたのだが，それはこちらの勝手な思い込みで・発表論文のほとんどはかなり細13

MeetingReport

SEAMAILVol．14，No．5

分化されたソフトウェア工学技法／ツールの詳細を論じたものが多い．わたしが今回参加した主な目的は，会議に併設して開かれるICSE2006準備委員会に出席すること，そして来年のSS2005の基調講演者に予定しているUCIrvineのAndrevanderHoekさんにお会いすることだったので，論文発表は個人的興味に合うものだけを適当に聴くだけにとどめた．
今回の会議場は，昨年の暮れにDynvPrqjectのUCIrvineMeetingのときに泊まったのと同
じSheratonNweportBeachHotel．チェックインのあと，ちょっと休憩して，やはりICSE2006

準備委員会のために来られたJAISTの二木先生と，去年クリスマス・ボート・クルーズを見物にいった近くの島まで散歩して，イタリア料理を食べる．

3日間の会議の朝一番はそれぞれ招待講演．講演者とタイトルは次の通り：
AlexWolf（UmiverSityofLugano）
IsSecurityEnglneeringReallyJustGoodsoftwareEngineering？

JoeMarks（MERI）
TheUsabilityProblemforHomeAppliance：EngineersCausedIt，EngineersCanFixIt
NancyLaveson（MIT）
MakingEmbeddedSoftwareReusePracticalandSafe

FoundationというよりはむしろApplication ofSoftware Engineeringに近い内容のように感じた．
ちょうど会議初日が大統額選挙の投票日にあたっていて，TVは一晩中オハイオ州の開票速報について，同じようなコメントを繰り返していた．会議に集まっていた先生方はほとんどがケリー支持で「なぜまたブッシュなの？」といささか諦め気味の表情を見せていたが，数日前に出されたビンらディンのメッセージが，ブッシュ再選を希望したかれの思惑通り，アメリカの一般大衆にインパクトを与えたのだろう．

6．APSEC2004（11／29−12／4，釜山）

この会議が韓国で開かれるのはこれで3回目になる．最初はまだ日韓ジョイントの会議だった
1992年のソウル），パネルに招待されて参加したのが，わたしの初めての韓国訪問だった．そして参加国が拡大されてAPSECになってから第3回目（1996）がやはりソウルでの開催．あの時は故・坂本啓司さんや伊藤さん，中小路さんが一緒だった．

その後の3年間，わたしは，香港（第4回），台北（第5回），高松（第6回）と連続してこの会議に参加している．1997年の香港では，坂本さんほかSEA・SPINのメンバーと一緒に，香港ProductivityCouncilとジョイントで併設のプロセス・ワークショップを開催，1999年の高松では，やはり中国・韓国の人たちを招いて国際ワークショップを開催した．
今回の釜山会議では，昨年11月ソウルでの組込みワークショップ，そして今年4月釜山でのJCSEでK．C．Kang先生や荒木先生たちと企画を話しあってきたPLSEに関する併設ワークショップの開催が実現した．

14

MeetingReport

SEAMAILVol．14，No．5

いざふたを開けてみると，日本からのPositionPaperはかなり集まったが，韓国からの応募が予想より少なかった．これはあちらの経済事情のせいらしい．一時の危機的状況をIMFの支援で乗り切ったかに見える韓国経済だが，実態はまだかなり苦しく，IT不況も底を打ってはいないようにみえる．某S社だけは元気がよいが，これにも蓑があるらしい．今回のAPSECin
釜山の場合にも，S社ははじめ協賛企業に名乗りを上げていたのだが，間際になってドタキヤン

韓国の先生方もかなり頭に来たようすだった．
ワークショップにはS者のエンジニアも何人か参加していた．そのうちの1人と夕食を一緒にしたとき，「どうなの？」と訊いてみた．「PLSEには個人的には興味があり，ぜひ現場に導入してみたいと思っているのだが，そのためにはいささか長期的な投資が必要．いまの現場にはそうしたことは許されそうもない．わたしの名刺の肩書きはReSearCherとなっているけれど

も，実際は研究職ではなく，現場のエンジニア．うちの会社には研究開発に投資をするという考
えはないみたい．よその会社や大学にまかせておいて，実用的な成果が出そうになったらその人をスカウトしてくればよいというのが上の考え．困ったものです」．それを聴いていた韓国の先生いわく「早く君が出世してそうした企業風土を変えてくれよ」．日本の大企業も，バブル経済が崩壊して以降，多かれ少なかれ同じような傾向にあるというのがわたしの個人的感想・
今回の会議の招待講演者は，初日がHassanGomaaさん，3日目がMaryJeanHarroldさん（2人ともGeor由a恥ch）だった．タイトルはそれぞれ：
Gomaa：〟Real−TimeDesignforEmbeddedSyStemS‥FromCentrali2；edControlto
DistributedComponent−basedProductLine

Harrold：

ImprovingtheQualityofdeployedSystemsthroughRemoteAnalysis，Monitoring，andTbstingであった．講演のスライドは会議のWebPage（http‥／／se．kaiSt．aC．kr／apsec2004ノ）に掲載されている．

G。maaさんの講演は予想したとおりのチュートリアル風の話で，それほど印象に残らなかっ
たが，MaryJeanHarroldさんの講演は内容が新鮮で興味深かった・かの女は，11月の上海ワークショップにも来ていたのだが，あのとき，かの女はSo私さんやClarkeさんと一緒に別のTrack（TbstingandAnalysis（このテーマはなぜか女性研究者が多い）に入っていたので，話をきくのは今回が初めてだった．
Georgialbchのかの女の研究グループは，いまGammaと名づけられたプロジェクトを進めていて，今回の講演もその内容紹介であった．プロジェクトのWebPage：
http：／／www．cc．gatech．edu／aristotle／Research／Projects／gamma・htmlには，その概要が次のように述べられている：
TheGammaprojectofGeorgiaTbchproposesanewapproachtoimprovesoftware
qualitythroughcontinuousmonitoring，analysis，andimprovementofsoftwaresystemsaftertheirdeployment．Themotivationfbrtheprojectisthefundamental

shiftthatwewitnessedintheworldofcomputing．Wemovedfromasituation15

MeetingReport

SEAMAILⅥ）1．14，No．5

Characterizedbyafewsoftwaresystemrunningonmostlydisconnectedcomputers
toasituationinwhichsoftwareisvirtuallyeverywhere，runSOnmOStlyconnected

COmputerS，andthereisalargenumberofresourcesavai1abletothesingleusers．
Thanktothisshift，Wehavetheopportunityofleveraging￡elddataandresources

toimprovethewayinwhichweperformsoftwareengineeringtasks．

ManySOftwareenglneeringtasksarelimitedbythefactofbeingperformedin−house，
Ondevelopers

platforms，andusingdeveloper−sprovidedinputsthatmaynotbe

representativeofthewaythesoftwareisusedinthefield．TbovercometheselimitationS，WeuSe丘elddataand resourcestoaugmentsoftwareengineeringtasks．

現在，われわれの周囲にある多くのソフトウェア・システムが，孤立した1台のマシンの上で稼動するのではなく，ネットワークでつながれた複数のマシン（コンピュータ，携帯電話，そのほか各種のデバイス）の上で分散して稼動していることは事実である．そしてそのシステムは周囲の条件の変化に応じて絶えず進化し続けている．そうしたシステム進化を遠隔モニタリングでフィールド・データを収集し，効率的な回帰テストを行ってシステム・メインテナンスがもたらす影響を分析するというアプローチは，まさしく王道を行くものといえるだろう．SMSG（ソフトウェア・メインテナンス研究会）で，今年はこのGammaシステムの行方をトレースしてみた
いと考えている佃伽：〟ww．smsq．or．iD仇16

WorkshopReport

SEAMAILVol．14，No．5

Proceedings

JbrlStJointWorkshoponEmbeddedSoftware

Nov．19〜21，2003
Seoul，Korea

β戯gdわ′

点わ〟C力点お力れ均〃C鳩〟属b〃g，〟〃dJbOか叩g肋17

WorkshopReport

SEAMAILⅥ）1．14，No．5

WorkShopO咤ani〜aIion□

GeneralCo−Chair
O KouichiKishida′SRA−KTL′JapanO KyoChulKang′POSTECH′Korea

口ProgramCo−Chair
O KeijiroAraki′KyushuUniversitY′）apan

O SungdeokCha′KAJST′Korea

口OrganizationChair

O ByongjuChoi′EwhaWomen′sUniversity′Korea□

ProgramCommittee

O TakaoFutagami′ToyoCorporation′japan

O MasahikoIshikawa，SRA′japan
O Masaolto′NilSoftware′）apan
O KeitaSato′Denso′japan
O SooYongPark′SogangUniversity′Korea
O KwangkeunYi，SeouINationalUniversity′Korea

O）angSooLee′KAERl，Korea

O HoonSunChang′KOPEC′Korea
OJinYoungChoi′KoreaUniversity′Korea
O SooDongKim′Soongsi＝」niversity′Korea

18

WorkshopReport

SEAMAILVol．14，No．5

TableofContentsl．TrackA．ProcessandPrdectManagement

l．1PositionStatements

KouichiKishida，KoichiSugahara，NorikoWada
1．2GroupPresentation

2．TrackB．TbstingandQualityContro1

2．1PoSitionStatements

IkukoSuzuki，MasahikoIShikawa，TakamasaNara
2．2GroupPresentation

3．TrackC．DevelopmentMethodandNewParadigm

34

3．1PositionStatements

SungwonKang，EunsookCho，SoodongKim，SooyongPark，
TaknoFutagami，MasaoIto，SeijiTbkimatsu，KeijiroAraki，NorihikoMatsuda，YbshikazuHayashi，AkiraFukuda，
Ybji％manoue，Hitoshi協mane，ShigeruHitomi
39

3．2GroupPresentation

19

WorkshopReport

SEAMAILVol．14，No．5

1TrackA．ProcessandProjectManagement
l．l IIositionStatememts

l．1．l KouiehiKis血ida

IhaveorganizedJASPIC（JapanSPIConsortium）3yearsago．Nowwehavenow24
membercompanies，andahalfofthemaredoingsystemsbusiness．Generallyspeaking，
those■lembedded

一

companies

are eager tO do CMM−related SPI activities thanothercompanieswhoaredoingordinary（ratherbusiness−0riented）softWarebusiness・

On of

the reasonis

embeddedsystemthat software becomes moreimportant Part Of

products．Those

MembeddedTI

companies

have

long

experienceinhardwaremanufacturingbutdonotknowabouttheprocessofsoftwaredevelopment．So，theywanttOnOrmalizesoftwaredevelopmentprocessbyuslngCMM
OrISOstandardasaguideline．

Ontheotherhand，Ordinaryso舟warehouseSarelivinginotherbusinessenvironment・So抒ⅣareSyStemSWhichtheyaredealingwithare

E−tyPeHsoRwarebythede丘nitionof

Prof二M．M．Lehman．HE■一meanSl．embedded一一，nOtin hardware，butin real world
applicationprocess ofradicalchange・So，theirsoftwaredevelopmentprocesses are

difnculttonormalizeorcontrol．EssentialcauseSOfthedifBcultyinfrontofthemmay
notbesoIvedbyCMMorISO・

Atthisworkshop，Iwouldliketo discusS aboutthenatureofembeddedsystemdevelopmentprocess，andtofindouttheproperdirectionof鮎山reimprovement・

1．1．2

二KoidliSⅦgahara

AfterdeveloplngVariouskindofembeddedsoRwareaboutlOyearS，Ibecamea

SEPGstaffwithinthecompany．Atfirst，OuraCtivitywassomehowad−hocstyle，and
couldnotachieveanyvisibleresult・So，WedecidedtouseCMMasaguidelineforSPI
activity．

ロ

Lessonslearned：（1）Importanceofprojectplandocumenttomonitorthestatusofactualpractice′especiallytowatchdeviationfromtheorlgInalplan・（2日mportanceofvisibIepresentationofQAresulttothemanagement・□

MYObservationaboutCMM：

20

WorkshopReport

SEAMAILVbl．14，No．5（2）TheremaybeseveralsubqstepbetweenleveH and20fCMM．
（3）WeshouIdprioritizevariouspracticesinIevef2．

□l．d Hくe tO PrOPOSe foHowing maturity model for embedded sYStemS
deveIopment：

O LeveH．2：Bugmanagement・isOK．
O Level1．4：RequzrementchangemanagementisOK．

1．1．3

0

Level1．6：ScheduLemanagementbasedonWBSisOK．

0

Leve11．8：QualityassuranceisOK．

0

Leve12．0：QuantitativeriskmanagementisOK．

NorikoWada

IwillpresenttheideaofevaluationmodelforSPIactivity（5evaluationparameterSOf

Organizationalchange）．thistalkisbaseduponherexperienceofSPIactivityinSony，

ItshowsatypicalexamPleofJapaneSeStyle一

21

Bottom−UPTfqpproachtoSPI．

WorkshopReport

SEAMAILVol．14，No．5

1．2GroupPresentation

l．2．1Agenda
Wehadfollowing8members：

FromJapan（3）：Mr．KouichiKishida（SRA−KTIJ
Mr．KoichiSugahara（FujiPhotoFilm）

Ms．NorikoWada（Sony）

FromKorea（4）：Prof・DoohwanBae（KAlST）
Prof．HyuksooHan（KSI）

Dr・HoonseonChang（KOPEC）

Mr．SeunghwaYi（LGInnotek）

Unfortunately，mOStOfKoreanparticipantscouldnotattendfulltime，becauseofsome
Otherbusinessappointments．

Wehadfollowing4presentationsfollowedbyquestion−and−anSWer

lstSession（Aftem00nOfDec．20）

Processimprovementactivitiesfromtheleve11totheleve12byMr．KoichiSugahara

Exploring relationships between organization culture and SPI activities

accordingtoIDEALmodelbyMs．NorikoⅥbda

2ndSession（MomingofDec・21）

ActivitiesofSPICKorea
byProf．DoohwanBae

ApplicationofEmbeddedSysteminNuclearPowerPlant
byDr・HoonseonChang（KOPEC）

1．2．2Presentations

l．2．2．1Mr．KoichiSugahara

ThetitleofMr．Sugahara

spresentationwas：

Processimprovementactivitiesfromthe

levelltotheleve12日．

Mr・Sugaharaisnowworkingasafu11−timeSEPGinFujiPhotoFilmcompanyafter
engaglngembeddedsoftwaredevelopmentfortheMimi−hbsystemsmorethanlOyears．
Hepresentedhisproposalofsettingupseveralsub−StePSinbetweenleve1−1andleve1−2

0fCMMphases・HesaidthataccordingtohisownexperienceasSEPG，thesesub−StepS

22

WorkshopReport

SEAMAILⅥ）1．14，No．5

willbeusefu1fbrguidingSPIactivitiesinembeddedsoftwaredevelopment・
Proposedsub−StePSfromLeve1−1toleve1−2areasfollows：

Levell．2：BugmanagementisOK．
Levell．4：RequlrementChangemanagementisOK・

Levell．6：SchedulemanagementbasedonWBSisOK・
Levell．8：QualityassuranceisOK．
Leve12．0：QuantitativeriskmanagementisOK．

ThepurposeofthisproposalistoprioritizevariousKⅣ旭inthecourseofSPHrom
leve1−1andleve1−2．Insuchasense，thegroupmembersagreedthatitwillbeuseful
SOmehow．

1．2．2．2Ms．NorikoⅥねdaThetitleofMs．Ⅵbda

spresentationwas：

Exploringrelationshipsbetweenorgamization

CultureandSPIactivitiesaccordingtoIDEALmode1日．

Sonystartedacompany−WideprqjectcalledSW21toevaluateandimprovesoftware

managementpractices accordingtotheSoftware CMM andIDEALmodel．Sheisa

member of corporatelevel staffteamto support several software development
Organizationswithinthecompany．

InSW21prdect，40rganizationswereselectedwiththegoalofachievingCMMleve1−2
within2years．Someofthemachievedthegoalandsomefailed．Ms．Wadaandher
COlleaguesmadeananalysisofreasonsofsuccessandfailure．Thequestiontheyhad
WaS：

Are there any elements to the success ofSPIactivities otherthanthe tasks

describedinIDEALmodel？H

So，theymadeevaluationoftheprogresofSPIactivities accordingtothefollowlng
hypotheticalequation：

Organizationalchange＝f（Environment【Internal，Extemal］，Activitiesforchange，Abilitytoacceptchanges，Previouscondition）

Foractualevaluation，theyslightlymodifiedtheequationasfollows：

Phaseachievementscore＝f（Environment，SpecificPracticeactivities，
GeneralPracticeactivities，Previousphasescores）

Afler careful analysIS Of40rganizations results，they observed severalinterestlng

23

WorkshopReport

SEAMAILVbl．14，No．5

Phenomena，andderivedanumberofhypotheticalknOwledge abouttherelationshipbetweenorganizationalcultureandSPIactivityprogress（Forthedetail，Seetheslidesin
appendix）．

Thegroupmembersdeeplyimpressedthedatashownandarelookingforwardfurther
Surveyinfuture．

1．2．2．3Prof．DooHwanBae

Prof・Bae made aninformal explanation about Korea SPIC（Software Process

ImprovementCenter），Whichisoneof32researchcentersundercontrolofITRC．

InSPIC，thereare4pr可ectsarerunnlng：

PSEE：Porcess−0rientedSoftwareEngglneeringEnvironment

SQA：SoftwareQualityAssurance
CMMSupportingProcess（Requirement，SCM，etC）
CMMManagementProcess（Metrics，Measurement，etC）

AsforPSEE，thegoalofthepr可ectistoproduceanintegratedprocess−OrientedCASE
toolenvironment，Whichwillbeadaptabletotheneedsofeachcustomer，in3years．
In porcess area，SPIC has already produced the guideline

for CMM／CMMI

implementationforsmall／mediumcompanies．Itisapracticalguideforimplementing
KRAstowardsleve12．

TheotherimportantmissionodSPICistotrainprocessexpertsthroughseminaror
WOrkshopln COOPerationwith KSI．AIso，teaCh process technologies to graduate
Studentsinuniversity．

It seems to be agoodidea to provide support tool environment with management
guideline・The action of Korean govemmentis quicker than that ofJapanese

govemment，andalsolittlemoreintegrated．

1．2．2．4Dr．HoonSeonChang

ThetitleofDr．HoonSeonChangwas：

ApplicationofEmbeddedSysteminNuclear

PowerPlant．．．

He explained the situation of software development and maintenance pr可ectsfor

nuclearpowerplantsinhiscompany．

Thepr可ectsarethoseofanalogsystemstodigitalsystems・Inthecaseofnuclearpower
Plants，Safetyismuchmoreimportantthanefficiency・So，tOaPPlynewdevelopment
methods，yOumuStbeverycautious．

24

WorkshopReport

SEAMAILVol．14，No．5

AIso there are a number ofstrict regulations and standards to fbllow．Development

life−CyCleis classicwaterfallmodelwith strictverification andvalidationbythird
Party・

Systemsaresafetycritical，andthedelayofdevelopmentcausesheavycostproblemsin
usersside．ItlookslikeyetanotherembeddedsystemswithveryunlqueCharacteristics・

1．3．GroupCoordinatorTsSummary（KouichiKishida／SRA−KTりInJapan，SEA−SPINwaskickedoffin1995．ItsmaJOraCtivityisinformationexchange
ViaML，regularo掛linemeetings，andworkshopsonspecialtopICS・Nowwehaveabout

120ML members，and more than50among them arefrom embedded systems
COmmunity．

AIso，anOn−PrOfitorganizationcal1edJASPIC（JapanSPIConsortium）wasestablished3yearsago．NowIthas24membercompanies，andhalfofthemaremanufacturing
embeddedsystems．

Thereasonwhy？

Thereisanessentialdifferencebetweenhardwaremanufacturingprocessandsoftwaredevelopmentprocess．Embeddedsystemspeopleareexpertsinhardwareprocess，but
theyarenoviceinsoftwareprocess．

Nowadaystheroleofsoftwarecomponentsinembeddedsystemproductsbecamemuch
moreimportant，and the size and complexity of those software has been rapidly

increaslng．So，embeddedpeopleeagerlywanttoleamffomsoftwarecommunity−sbest
PraCtices．

Intnepaper

WhytheVasaSank？

（IEEESoftware，March−April，2003），ProftssorDick

Fairlypointedoutfo1lowinglOproblemsinprocessmanagement：−Excessiveschedulepressure−Frequentlyhanglngneeds−I．ackoftechnicalspecification−Lackofadocumentedprojectplan−Excessiveinnovation−SecondarylnnOVation−RequlrementSCreeP−IACkofscientificmethods−IgnorlngObvious−Unethicalbehavior

25

WorkshopReport

SEAMAILVbl．14，No．5

Tbdeterminewhichoneismostcriticalinthecaseofembeddedsystemsdevelopment，

WeWillneedtodomorecarefulanalysisofvariouscasestudies・WhenweperfomSuChananalysis，WeShouldbecarefulaboutthemeanlngOfHembeddedH．

Inthefamoustheoryofsoftwareevolutiondynamics，ProfessorM．M．Lehman（Imperial
College，UK）notifiedthatthereare

2typesofsoftwarearoundus：S−tyPeandE−1㌢pe．

S−tyPeis the software which we can specifypreciselyin advance，fbr example
mathematicalcalculation subroutines，etC・namely，‖SH means−ISpecinable一㌧On the
Other hans，E−tyPe SOftwareis HEmbeddedHin real world application process・Specificationchangescontinuously，becauserealworldischanglngCOntinuously・Wearenowdealingwithsoftwaresystemwhichisembeddedinsomehardware．They
havemixedcharacteristicsofS−andE−tyPe．SomecomponentsareS−tyPe，butsystem
asawholeisE−ytyPe・Mixingratevariesdependinguponapplicationdomain：homeelectronics，industrialcontroIsystem，nuClearpowerplants？etC・AIso，Whenwe discuss aboutprocess，WeShouldbecarefulaboutdifferentprocess
SPaCeS・Thereisahierarchicalnestingstructureofprocesses：−Programexecutionprocess（insidehardware）−Systemdevelopmentprocess（OutSidehardware）−¶∋Chnicalaspects−Managementaspects−Systemoperationprocess（inapplicationprocess）−Systemevolutionprocess（insocialprocess）

Andtherearecomplexrelationshipsamongvariousprocesscomponents．Inasimple−Relationshipbetweenhardwareandsoftwareinprogramexecutionprocess

SpaCe−Relationshipbetweensystem（hardware＋SOftware）andhumanpr可ectteam
insoftwaredevelopment／maintenanceprocessspace−Relationshipbetweensystemandsociety（users／market）insystemevolutionprocessspace

So，Whenwe discuss aboutprocessproblems andprocessimprovement，atfirstwe
Shouldorientateourselvesproperlyinwhichwearein．Thefourpresentationsinour
groupcontainmanyinterestinglSSueSinvariousprocessspaces・Wewi11beabletoget

SOmeuSefulknOwledgebyanalyzingthem fromproperperspective．Itisthetaskof
discusiionsinfutureworkshops・26

WorkshopReport

2

SEAMAILVol．14，No．5

TrackB．TtstingandQualityContro1

2．l PositiomStatements

2．1．1IkⅦkoSuzuki
IamnOWinvoIvedinvariOusembeddedsystemdevelopmentsuchasmobilephone，etc．Inthepast，IhavedevelopedCAD／CAEsystemsandalsoDBMS．

The size of so倉ware embeddedin variOus home appliance products has been

increaseddrasticallyinrecentyears．AndqualityassuranCeOfthosesoftwarebecomesmoredifncult，becauseoftheshortenlngOfdevelopmenttimecausedbyrapidchangein

marketneeds．

Generallyspeaking，theratio oftestingintotaldevelopmentactivityisincreasing．

TestingcannOtaSSurethequality，butitisstillveryimportantcentralactivityinQA．

Ibelieve that high qualitydesignis essentialto planand performefRctiveand
COmPletetesting．Atthisworkshop，Iwouldliketo discussthisrelationshipbetween

designandtestingwithKoreaneXPertS．

2．1．2

Masa血ikoIsbikaWa

Thereis a strong trend of using open−SOurCe SOftware（OSS）in embedded

SyStemSdevel0Pment．But，itis noteasy．

ToutilizeOSSe脆ctively，uSerSneedtohavefairlyhightechnlcalknowledgeand
experience．becauseOSSareprovidedtopublicwithnocustomersupportnotlikelyas
COmmerCialso氏wareproducts．

Ithinkthatfollowlng tWOissues areimportantfortheuse OfOSSin embedded
SyStemSdevelopment：1）HowtodownsizeOSSinorderto丘tintothelimitedmemory

SPaCeOfembeddedsystemproducts．2）HowtoconductqualityassuranCeaCtivity．It

may be rather difncult because various customization are made to OSS source
code．

Yetanotherissueisthehandlingofmultibytecharacters．Itisoftheweakpointso

SOmeOfsomekindofOSS．Iwouldliketodiscusstheseissuesattheworkshopandto
ShareCOmmOnCriticalmindwithKoreanexperts．

27

WorkshopReport

2．1．3

SEAMAILVbl．14，No．5

Takama＄aNara

IhavebeenworkinginQAdivisioninthe companyandbeenconductingtesting
and／orqualityassuranCeaCtivitiesforbusiness叩Plicationsystems．

Mym毎orconcems are：SOftware reliability，developmentprocess，teSting，Pr亘iect
management，etC．

Ⅰaminterestedto貢ndoutwhatis commonand whatis di飽rentbetweenbusiness
SyStemSandembeddedsystems．Thentherewi11beapossibilityoftechnologytranSfer．

2．2

GroupPresentation

KoreanParticipantsinthegroup20nteStandqualitycontrolincludeSung−DeokCha（KAIST，COOrdinator），Hoon−SunChang（KOPEC），Kee−ChoonKwonPRI），Jang−
Soo Lee（KAERI），Han−Seong Son（KAERI），Sang−Sup Song（ADD），Jong−In Lee（KARI）．Weallhavecommoninterestinthatourprimaryinterestliesinfomalmethods
andsafbty−Criticalembeddedsoftwareapplication．Forexample，mOStOfusareinvoIved

withdevelopmentandqualityassuranceaspectoftheKNICSprqjectwhosegoalisto
developourownSOftware−COntrOllednuclearpowerplantinstrumentationandcontroI

SyStem．S．S．Song，amanager atADD，WOrks onqualityassuranCe Ofsoftwarefor
military applications．Jong−In Leeis a chief architect of KOMPSAT softWare．

KOMPSATisasatellitebeingdevelopedinKorea，andneedlesstosay，thesystemis
Saftty−Criticalandsoftware−intensive．Whenaddressingqualitycontrolaspectofsafbty−
Critical software such as KNICS，Safetyanalysisis alsoincluded becauseitis an
essentialingredienttothequalityassuranceprogramandgovernmentapprovalprocess・

BasicqpproachtotestingandqualityassuranCeisfundamentallybasedonthenotion
Offbrmalspeci丘cationand veri且cation．For examPle，inthe KNICS prqiect，We

re

SPeCifyingsoftwarerequirementsusingnotationcalledNuSCRwhichwe developed
basedonSCR（SOftware costreduction）prqjectatNRLintheU・S・Whilebasicallyadoptingtabularnotation−CalledeitherstruCtureddecisiontableorAND−ORtablein
literatwe−NuSCRincorporates graphicaland timed automata to visually specify
requlrementSrelatedto systemstatesandtransitions・FromNuSCRspecification，We

havedevelopedrulestoautomaticallygeneratedesigninfunctionblockdiagram（FBD）
whichis aprogramminglanguageforprogrammablelogic controllers（PLCs）．Since

designinFBDismechanicallycompiledbyaCASEtooIsuchasthe SpacetooIset
developedbySiemens，FBDshouldberegardedasimplementationlanguage・28

WorkshopReport

SEAMAILVol．14，No．5

Our researchinterestliesin how we can ef托ctively（and whenever possible
automatically）perfomVarioussafttyanalysisincludingfaulttreeanalysisandgenerate
test cases．For examPle，We are alsoinvoIvedin research where test casesare

automaticallygeneratedfromStatechartsspecificationorNuSCRspeci負cation．Weuse，

likeotherresearchers，mOdelcheckerstogeneratetestcasesaccordingtotheselected

Criteria．FaulttreeanalysisbasedonNuSCRandFBDisalsothesu切ectofcurrent
researChinprogress．

DespitetheuseOfformalmethodsandmodelcheckingteclmiquestoaidtestingand
qualityassuranCetaSks，WeStillseeopportunitiesforfurtherresearchonthefollowing

topics．Letme，Onbehalfofthegroup，brieflysummarizethembelowandwelook

forward to discusslngthese and other teclmicalissueswith distinguishedJapaneSe
PartlCIPantStOtheworkshop．

E］Testingofhardware／softwareinteraction．When usingembedded softwarein
reaトworldapplications′itisknownthatunknownandsubtleerrorsmayoccur

duetounanalyzedpatternofso什wareandhardwareinteraction．Howonecan
effectivelYteStSuChinteractionis′inouropinion′animportantresearchtask・口．Modelingofenvironmentin which embedded software／systemistooperate・
Analysis ofembedded softwareinisolation，Withoutp〔PPer COnSideration ofenvironmentalfactors，is at bestideal．Often′SUCh nalVe teStingis outrightunrealistic．How one can effectivelyincIude environmentinto testing andqualityassuranceprocess／taskisoneofourresearchinterest．

ロ

QuaHtY meaSurement Of test cases．Using modelchecker and welトdefined
COVerageCriteria′OneCan generateteStCaSeS・HowusefuJarethey？Somein

research communityspeculatethattakingwhatevertestcasesgenerated bya
modelchecker（e．g．′SMV）basedonthecriteriaisnotthatusefuHnthattheyare
not that usefu暮in detecting potential flaws．There could be manY

COuntereXamPIesthatmayviolatethepropertyweareinterestedin・Howdowe（Or Can we）influence／controlmodelchecker so that〝quality test cases〝are

Pickedup？
E］Code−basedverification．Researchon codeverification and modelcheckingis
activeinresearchcommunity′andthereareusefultooIssuchasBanderatooIset
and Verisoft．Some are usedin reaトworld projects with SUCCeSS．Are they

appHcabletosafety−Criticalsoftwaresuch as KNlCS？Cantheybeapplied〝asis〝？

Groupontestingandqualitycontrolforembeddedsystemsfirstnotedthatthereare
SeVeraltypesofembeddedsoRwareandthatdi飴rentqpproachesareneededtoperformthemoste飴ctivetestingandqualityassuranCetaSks・Asshownbelow，afterlengthy
discussion，thegroupagreedtoreviewthefollowingthreegroupsseparately，identify

29

WorkshopReport

SEAMAILVol．14，No．5

Characteristicsthatin且uenceourrecommendedchoicetotestingandqualityassuranCe，

andcomparedifRrencesbetweenthem．Theyare：□

Amarket−drivenenvironmentinwhichrequirementsforembeddedsoftwareare
relatively stable・For example′SOftware embeddedin vehicle（e．g．′Cruise

COntrOl，ABScontroLetc）areobviouscandidates．ProductLife−timeisrelatively

extended（especiaHy when compared to software embeddedin consumer
electronics）．

E］Amarket−drivenenvironmentinwhichrequirementschangefrequentlY．ltisno
SurPrisethattypical＝fe−timeofacellularphonenowadaYSareLessthanafew

monthsandthatcompaniesintroduceseveraldozensofnewmodelseveryyear
tostaycompetitive．Whilemuch ofbasicsoftwareembeddedin such ce‖uJar

PhonesisundoubtedlYreuSed′SizeofsoftwarebeingdevelopednewforeachmodeHsexpectedtobesignificant．TestingofsuchsoftwaremustbecompJeted

inashortperiodoftime（evenwhenmeasuredbyman−mOnthsallocatedtothetask）′anddifferentapproachesareneededwhencomparedtoqualitYaSSuranCetaskforsoftwareembeddedinavehicle．

□

Thethird′yetCOmPletelydifferentenvironmentfromtheviewpointofquality

COntrOlforembeddedso什ware，istheenvironmentinwhich softwareperform
SafetY−CriticaJtasksandqualityassurancetaskiscJoselyrelatedtogovernment
regulations and approvalprocess．Software controHng emergency shutdown

SYStem for nuclearpowerplantsisan obviousexampfe．ln fact，in Korea′the
WoIsung nuclear power plant has software−implemented shutdown system

Whichisinoperation′andthenextgenerationsYStemfornuclearpowerplantis
in development using formalmethods′and many ofthe participantsin thegroupactivelycontributetotheproject．

For three di飴rent types ofembedded software，followingidenti丘cation ofkey

Characteristics that stronglyinfluence desirable approaches to testingand quality
assuranCe，the group begandiscusSion onthe recommended practices on softWare

developmentpracticeaswellasqualityassuranCe．Resultsofthegroupdiscussionare

Summarizedbelow：

MarketDriven−

StableRequlrementS：￣髄論藻鉦鎮魂壷毎一圭

・Jもてて ▲ 二．

SafetyAnalysis

COmplexi呼Regulated−

Frequently Changlng RequlrementS

一章三告‥心三二1く＿．亮緩−Sa先年analysisis

OPt10nalbut recommended

Con仕011ed

MarketDriven−・一・・一こ・−ト∴・雪二王；Jト．サ三 準輿論謳塞≡搬棄毒

Nosaf呼analysis

SeemSneCeSSary

Desiral）le

Sa氏tyanalysis

mandatoryto Obtainoperating license

Maynotbe

desirable／essential

30

Sbble RequlrementS

Absolutely
essential

WorkshopReportMarke〟Duplication

SEAMAILVol．14，No．5

Many（100，000＋）、ゝ：r

ALot（1，000，000＋）

Several（10＋or l＋）

ヽ・・

・Development二・∴・一・智roぐやSS−，・し∴、・・lJ一・い血▲・、11Req．／Design（Howmuchextensively

apply

二

r■、

∴壬▼∴

∵／

Formalmethods「■・■

ト1＼仰∴三・・・、■・J・‥一、1

Highlyis・reCOmmendable．

requiredaccordingfortothecriticality（ex．

QCrIbsting？）ノ

UMLbasedmethod

maybeadditionallyformalmethods∴三一f∴〟17

ABS，Airbag

recommended，Japanhasan

buttowhat

experiencethat

QualityFunCtion

degreeshouldwe

usethefbmal

Control） Deploymentrrhguc himethodsare appliedforthe developmentof HomeApplications， Navigation Systems，etC． methods？

Ex仕emeUnlikelytobe

Forsmallprqjects

Highlyunlikelyto

PrOgramming？ acceptable （less血anl0−20 members），XP seemsdesirable． B山鉛rla喝e prqiects，Seebelow beacceptable，but SOmePraCtices arerOutinely 叩Plied（ex．Tbst− 丘rst）

1−1＼・−｝￣．

Qualincationoftest

SeeFiguresland2attachedbelow（The丘gureissuppliedby

CaSeS（Howmany kn0wndefectscan WereVealthrough thetestcases？How CanWejustifythe e伍ciencyof也e test？） Mr．ThkamasaNaraandcontainsJapaneSeteXt．）

Tbstprocess（Which

Integration／Systemtestactivitiesshould

We
Can

Perform？How
yOu

test（includingh／Wands／wintegration

allocate

testingbudget？

Integration／Systemtest（includingh／Wands／wintegrationtest）ismoretest）ismore

importantthanunit

Integration／Syste

mtest（includingh／Wands／W

integrationtest）is

importantthanunit

moreimportant

test． test．Standardized testcompletion guidelineshouldbe CuStOmizedbyeach COmpany thanumittest． Umittestisalso mandatory．

Independenceof

V＆VrIbsting

recommended（InHighlyIndependenttestlng

practice，Our

iscommon，but
independent

understandingisthat
ⅠⅤ＆Visnot COmmOn）

31

veri負cationisnota
COmmOnPraCtice

Requiredinthe
regulation

SEAMAILVol．14，No．5

WorkshopReport

Inspection，OrtypicalQAactivities

ThegroupnotedthatinspectionissuchabasictaskforQAprocessandthereare
Obviousnodi飴rencesonwheninspectionprocessesareinplace．

ThegroupalsonotedthatextremeprogrammlngPraCticeisunlikelytobeusefulin
hardware−intensiveembeddedsoftware systembecauserequlrementSdonotchange

丘equentlyanddevelopmentinisolationisdifncult

Ⅰ開発工程別不良摘出状況l
99．9

100

［

9

0

100

95．2紛4．7捌
94．4

l0．86 ⇒

8

0 78．4
T

7 0

比

2

にご〉

確立的手法

統計的手法

MT

33．7

2

返し ・QF ・FR CST （凡例） MT：ModuleTest

CT：Connec

TT：To

0

4立

・5倍
返し倍

検査アクション1

率 5 ％0 ヽ＿一′ 4 0 30

検査アクション2
方＃場 15．2 枚杉杉拐彰
0．8

CT 41．9

喜

1

79・2

2．7

t

tion

alTes

QP：Quality

Tes

t

t

Probe

FRCST：品質予測プログラム
00

MT ￣TT（forec

QP

設計 見直し

不

良

検

ast）

検査 P

出

Figure2−1

32

工

設計 見直し程運用

WorkshopReport

！▼、■■

−亡

D揖■

べ．J■・

SEAMAILⅥ）1．14，No．5

、

仙thod

恥n

0

10

20

30

48

TestInstance Numbe・r
HのGOnpt∋rt：正A皿ExpoctedFt1血N皿ber nこ950
伽山luコl hults rlIユnber

0ftと11＝dttl：

462

■＝0

）

＝3

＝＞

■コ：512．516

札＝0＿1■18954

も＝18＿4822
S

副旺・tPP工＞SS

1∃402＿444

476216■l S

三＝

0＿109522

も三0●0994497

も＝0＿912932＝

1＿393638・●・008

D＝三〇＿257754

Figure2−2

33

5

＝＝

1＿726028・●−006

D＝；0−181593

WorkshopReport

3

SEAMAILVbl．14，No．5

TrackC．I）evelopmentMethodsandNewParadigms

3．l PositionStatements

3．1．l StIJlgWOnKang，ArchitecturalIssuesinPervaSiveCompllting

InthepervaSivecomputlngenVironment，COmPuterSOftWareShouldbedesignedsuch

thatitcanCOntinuouslyattendhumanuSerS

needsandaqjustthemselvestoservehumanneedsinanefncientway．GiventhatsoRwareisforchange，themoresointhepervaSive
COmPutlngenVironment，WeareinterestedinanSWeringthefollowlngqueStions：

WhataretherequlremerrtSforthearChitectureofsuchsoftWare？WhatarChitectural
aspects should embedded software havein common

environment？

inpervaSive computing

Shouldindividualsoftware be builtwitha certainarchitecturethat

reflectsthosecharacteristics？Orwoulditbebetterifwehavesomesortofmiddleware

thattakecareofthecharaCteristics？HowsoonarewegolngtOberewardedbyadopting
thenewapproachtoarChitecture？Whatisthestatusofthecurrentneedforit？

3．1．2

EunSookCho，AdoptingUMLfbrModelingEmbeddedSoftware

ThegrowlngdominanCe OfsoRwareinembeddedsystemdevelopmentrequlreSa
Carefullook atthelatestmodelingtechniquefor software speci丘cationand design・

UMLextensionforembeddedsoftwaremodelinglSOneOfthoseefhrts．Firstofal1，I

wouldlike to show existing modeling teclmiques or methodologiesfor embedded
SO氏waredevelopment．

Second，Iwouldliketopresenttheneedsofandthecapabilitiesandlacksofcurrent
UMLforembeddedsoftwaredesign．AIso，IwouldliketodiscusstheelementsofUML
extensionforembeddedsoftWaredesign．

3・1・3

SooDomgKimナMe仙odolo訂払rDevelopEmbeddedSo什ware

Embeddedso氏waredevelopmenthasasetofcharacteristicsthataredistinguished丘omtraditionalsoftWaredevelopmentapproach．Inembeddedso食waredevelopment，

thehardwareandsoRwareareCO−designed．Thereisdiversityonhardwareandsoftwarefor embedded systemincluding device heterogeneity・Asthe market grows，thecompetitivenessislargelydrivenbythetime−t0−market・Toshortenthetime−tO一market，
theconceptofintellectualproperty（IP）isintroducedasareusableasset・

34

WorkshopReport

SEAMAILVol．14，No．5

MeanWhile，thecomponent−baseddevelopment（CBD）andproduct−lineengineering（PLE）aretWOemergingso舟wareengineeringapproaches，andtheyarewidelyaccepted
insoRwareindustry・Thesetwoprinciplesarekn0wntObeefRctiveinreusingdesign
andreducingdevelopmenteffbrt．

Byconsideringthecharacteristicsofembeddedsoftware，Irealizethatthekey

mechanismsofCBDandPLEcanbewellqppliedtothedevelopmentofembedded
SO允ware・Moreover，itshouldbeftasibletode血eacommerciallevelmethodologyto

developembeddedsoftWarethatisbasedonCBDandPLE．Iwouldliketosketchhow

the generalpnnciples of CBDand PLE canbe utilizedin embedded softWare
development

3・1・4

SooyongPark

EmbeddedsoftwareenvironmentsaregettingmorecomplicatednowadaysduetoincreaseddemandsonsoftwarefunctionalitiesandmoreinteractionsamOngSyStemS．
ForexamPle，mOrethan80％ofautomobilecontrolunit，Sfunctionalitiesaredoneby
SOftwareanditsroleisincreaslng・FurthermOre，thatsoftwareare血eractingwith0thers

SuChasmaintenanCemanagementSyStemandnetworkingsystem．Thatleadsmore

expectedoruneXPeCtedenvironmentsandfunctionalchangeSduringruntime．Todeal
withthesechangeS，SO氏wareneedstobeselfadaptableduringruntime．

TheselfadaptablesoftwareevaluatesitsownbehaviorandchangeSitsbehaviorwhen
theevaluationindicatesthatitisnotaccomplishwhatthesoftWareintendedtodo，Or
WhenbetterfunctionalityorperformanCeispossible．

DevelopmentofselfadaptablesoftWareraisesalotofresearchissuesincludingロHowcanwegetinformationfromrunningso在ware？

。Howcanwemakeajudgmentwhatwentwrong？
□

Howcanweadapt？

E）Howcanweverifytheresultofadaptation〜

Throughthisworkshop，IwouldliketosharecurrenttrendsinselfadaptablesoftWare

researchanddiscusshowwecanaCCOmPlishthatgoalbyutilizingorextendingour
researchactivities・ForexamPle，WeCandiscusSeXtenSionofsoftwareproductline
approach，SOftwareagentteclmology，Oradoptingformalmethodtechniques・AIso，Ⅰ

35

WorkshopReport

SEAMAILVbl．14，No．5

wouldliketodiscussproperapplicationdomainthatwecanPutOur・reSearChe放）rttO
PrOVeOurCOnCePtS・

3．1．5

TakaoFutagami

Thereare manydevelopmentmethodsforsoftWare developmentwhichhas goodenglneeringbackground・SomeofthemhadqppliedtoembeddedsoftWaredevelopment

sofar．Eachdevelopmentmethodhas specincpointandcanbeappliedto specificdomain．UMLandOOisoneofthemwhichsomepeopleexpectstobedominantin
near餌h∬e．

IliketodiscusShowtoexploitUMLconceptandideainsmallscaleembedded
softwaredevelopment・ⅠamgladtoshowhowweareincubatingembeddedenglneerS

withUMLideainJapan．ThiswaspresentedinEmbeddedSoftWareSymPOSiuninOct
2003．
＊＊ReportofUMLeducationforembeddedenglneerS＊＊

LargescaleUMLdrivenembeddedapplicationdevelopmenteducationprogramWaS
completedintheyear2002and2003・Morethan100traineesreceivededucationand
leamed howto use UMLand howto叩Plyit toimplementation．This experience

introducingussomeinterestingperspectiveforeducationandresultthroughmodeling
COnteSt．

3．1．

MasaoIto

Describing．一time

inreal−timesystemdesign，andsomepossibilitiesoftooIsupport

Thereare many WayS tO describethe time factorin real−time system design（i・e・temporallogic，mOdelchecking）．Butinpractice，itishardtoapplythoseapproach，

becausethosesystemsarerurmgOnaSPeCialenvironmerrtintermOftheresource
constraints．

Wepresentawayofsimpledescriptionoftimetohandlethissituation，andproposea

toolimplementationinordertobridgethegapbetweentheoryandpractice・

3．1．7

SeijiTokimatsu

hdevelopingprototype soRwarefrom aformalspeciBcation，We havetogetan
executal）le code that matchesthe specification．We choose Erlangfor wdtingthe

executablecode．Erianghas severale飴ctivefeaturesforanembeddedsystem．For

36

SEAMAILVol．14，No．5

WorkshopReport

examPle，real−time，fault tolerantand so on・Althoughitis afunctionallanguage，
PraCtical．

We researCh developlnganembedded system uslng thefunctionaland practicallanguageErlang・Inthisworkshop，WePreSentaCOdegenerator丘omVDM十十toEriang・

3．1．8

KeijiroAraki

Weintendtoproposeasystematicande飴ctivewaytodevelopembeddedsoftwaresystems based onformalmethods・Itwillsupportto modeland describe domains
concermng embedded system development・Especially，We hope to叩Plyformal
methodsin describe domain models，PrOPOSearChitecturesfor embedded so魚ware
systems，PrOVide e飴ctive ways toanalyzeand detectlogicalerrorsand ftatureinteractionsattheearlierstagesindevelopment．

Wewillbrieflyintroduceseveralformal叩PrOaChesandtooIs，anddiscussabutthe
POSSibilitytoapplythemtoembeddedso氏WareSyStemS・

3．1．，

Nor姐ikoMatsuda

OurorganizationisdevelopingFactoryAutomationComponents・Thesecomponents

areusedinfactoryformanyyearS．So，qualityisIstconcemingpoint・Andadditionally，Consideringcurrentbusinesscondition，quickdevelopmentbecomeimportantmatter・

TosoIvetheseproblems，ⅠamVerylntereStinnewparadigmPLSE・ⅠamgladifIget
somepracticeofPLSEadaptationinthisworkshop・

3．1．10YoshikazuHayashi

IwanttOdiscussProductLineEngineenngwith0therparticipantSand，throughthe
discusSion，WanttOemPhasizetheimportanCeOfformingandmaintainingacommunity・
Reuseisakeyinengineeringproductivity．ForexamPle，OmronCorp・，aJapaneSe
leadingembeddedsystemscompany，foundproductivityofthedesignersbecamefour

timesasmuchovera丘veyeartimeofperiodbypromotingreuseWhilequalityofthe
finalsystemsgotbetterl1］・

TheconceptofProductLineEngineeringisarelativelynewbutprospective（See，for

examPlel2］）．Itisamorerealisticmethodforpromotingreuse・Todayrsengineering
prqiectsaregettingmoreandmoretight−budgetedandshort−termed・Withoutproper
effbrtsforincreasingoverallproductivity，engineeringorganizationswillbeleftbehind

37

SEAMAILVol．14，No．5

WorkshopReport

andboundtodisappomttheircustomers．Thatisevenmoretrueinembeddedsoftware
SyStem englneenng，wi1ere，because ofglobalcompetition，SyStemS are muCh more

COmPlexandthepressuretonotallowa鮎rNreleasedeficiencyismuchhigher．

AsIdiscussonabovetopics，IwanttOmakethefollowlngPOint・W旭etheworkshop
ParticipantSmaygatherpnmarilyforknowledgeexchange，thetrueValueofworkshops
Ofthiskindistosharethesenseof

oneness・

Knowledgebyitselfispowerlessunless

those who tryto useitfeelcormectedwiththeir goals，belief岳，and commmity．

CommumicationisnomereknowledgetranSftrbutfindingsomeonewhoshareSyOur
SenSe．

Referencesl1］SakamOtO，K・Kishida，K・，andNakakqji，K．，，．CulturalAdaptationoftheCMM：A
CaseStudyofaSoftwareEngineenngProcessGrouplnaJ叩aneSeManufacturing
Factory，一ISo舟W訂eProcess，JolmWiley＆Sons，WestSussex，England，1996，PP・137−

154［2］Kang，K．C．，Lee，J．J．，and Donohoe，P．，MFeature−0riented Product LineEngineenng，一一IEEESoftwareJuly仏ugust2003issue，PP・58−65

3．1．11Name：AkiraFukⅦda

SoftwaredevelopmentconsistsofmanyStageSSuChasfrommarketingresearchandformaldescnptlOnStOaCtualsoftWaredevelopmentandimplementingit・Eachofthem

hasbeendevelopedindividuallyandseparately・ItseemsformethattherearenO
methodsthat connecttheses stages；there are no seam1ess methods．I think that

PrOPOSlngand developlng Seamiess methodsand methodologiesisimportantfor
embeddedsystems

3．1．12YojiYaman川e

TheWebservicesarChitectureisanewparadigmbeingexpectedtoplayaprominent
roleindevelopingnextgenerationdistributedsystemsandembeddedso食waresystems．

WeresearChcurrent cases ofWeb servicesandaddress dependabilityinthe Web
ServicesarChitecture．Inparticular，WeaPPlyformalmethodforWebservices．

3．1．13HitoshiYamane

IamWOrkingasanSOftwareenglneerfordevelopmentofplantPrOductionlines
COntrOIsystems・Iwant to discuss Product Line SoRware Engineenngandits

adaptationtomyproblems．

38

SEAMAILⅥ）1．14，No．5

WorkshopReport

3．1．14Sh短eruHitomi

Icoordinate teanSfor realtime soRware englneerlngforIndustrialAutomation
domain．One of my recentinterestsis how we canreVOlutionalize our systems

development．ProductLineSoftwareEngineerlnglSagOOdcandidate・Iwouldliketo

seekdiscusslngCOlleagueswhomIcaneXChangeViewsandoplnlOnSwithoncontroI
so放W訂eSyStemSdevelopment・AndI叩PreCiateitifIcouldalSodiscussmanagement

issueregardingirrtroducinganewparadigmintoorganizationswhicharesoakedin01d
developmentstyle・

3．2

GroupPresentation

3・2・l Topic＃1・ProdtlCtLineTechnology

E］HowFODAdndKobraneedtosupportembeddedso什ware
O FODAismainlyusedfordomainanalysis・0−tis suggested that combining key constructs and eLements of various

methodsisafeasibleapproach，rather than usingasingle method・（Prof・Kang）

O CandidateMethods＞

Kobra，FODACOM′FORM′FASTE）ModelVariation Points
O howto坦entifY＿＿Variationpoints

O howto也variationpoints（reqs′arCh，COmP・）0些hanismstoimpleme叫＿VariationpointsandtheirquaHtyproperties＞

Maintainability′ReIiability

O PerformanceIsSueWithlmplementingVariationPoints
O Handlingevolutionofvariationpoints
O howtotracebetweenvariationpoints

o howtomodeldomainknowledge＞

口WhatknowledgeweneedtomodeJ

Goal−DrivenModelinginEmbeddedSystemsisessentiaL
O Separatespecificationfromimplementation・□

FollowedbyFeature−OrientedAnalysis

E）EachfeaturewHIberealizedintermsofobjectsandfunctions・□

Life一叩CleModels

39

WorkshopReport

SEAMAILVol．14，No．50lstheincrementaImodeIappropriate！
O proactivevs．reactiveproductline＞□

ProsandConsforeachapproach

ConfigurationManagement
O HowcanwehandleassetevolutionandappIicationspecificchanges？
＞□

MorestakeholdersforPLEincludinghardwareparticipants

ProductIine tooIs that handle variation points and support reuse（PatternS′

frameworks，Styles′COmPOnentS）

O requlrementSO architectures
O designs
O codeO configurationmanagement

O AtooIsupportingprocessenforcemenumanagement
3．2．2

Topic＃2．ProductLiJleAdoption

tj Technologyadoptionissues
O Howtotransfertechnologyfromitscreators／enhancerstousers（engineers）？

O How to make engineers who are knowledgeable of the target productdomain，thetechnology′andgoodsystemarchitectures！

O Howtoensuretheengineersknowthebasics＞

00ingenerar，mOdelingskiHs′domainanalysis′etC．

O Adaptation of the concept to the running environment with Hmited

O LackofCASEtooIsthatareawareofthePLSEprocessE］Suggestions
O

2．1．1
＞

Tutorial，Workshop′＞

SpecjalInterestgroup，＞

CoJlection of PLSE−related materials′tranSlatedin thelocallanguage（WiththecopYrightholders＞

O

CasestudY′SuCCeSSfulshowcase

2．1．2

＞

permission，Ofcourse！）

2．1．1＋Mentor

40

SEAMAILVol．14，No．5

WorkshopReport

0

2．1．3
＞ Tutorial＞ Reading＞O

Crouplearning

2．1．4
＞

Providingdevelopment／maintenancetooIsthatinterfacethehigher−level

designandtheactualprograms
E］ProcesspreparationO

2．2．1ManagementProcess＞

Organization−Wideconfigurationmanagement−＞Complexbecauseof

morestakeholders＞

Coreassets′＞

PrOducts′

Development plans

ChangecontroI，etC−＞concurrent H／W′Core assets S／W′Product

S／W
0

O

2．2．2EngineerlngProcess＞

TechnoLogyadoptionprocess＞

Coreassets／productsdevelopmentprocess

2．2．3MarketingProcess＞

MarketingdivisionandengineeringdivisionshandinhandE）SuggestionsO0

2．2．1′2．2．2

SPl（Ag‖e？Light−Weight〜）

2．2．3UseaFeatureModelasacommunicationmeansbetweenengineering
Staffsandmanagement／marketingE）2．30rganizationalManagementO

2．3．1Businesscase

＞ RO1
0

2．3．20rganizationalchange＞

O

StrUCture

2．3．3Seniormanagers−Commitmentfororganizationalsupport

E］Suggestion
0

3・2・3

2．3．1′2．3．2′2．3．3

SuccessstoriesofpracticaJadoptionfromcompanies

Topic＃3・tJtiliZingUMLfbrDevelopingEmbeddedSoftware

C）MotivationforUMLProfileforPLE

41

SEAMAILVbl．14，No．5

UMListhemostcommonnotationalconventionformodeHngsoftwaresystems．
However′embeddedsoftwaredeveIopmenthasasetofcharacteristicsthatarediStinguishedfrom traditionaZ software developmentapproach．AIso，PrOduct−lneengineeringhasefementsandconstiuctsthatarenotdirectlysupportedby
UML．Hence′itisnecessarytodefineanextendedsetofUML−basednotationaIconventionand semantics．

口

RepresentingFunctionalView

Usecasemodelcanbeusedtocapturetheprimarysystemfunctiona＝tyofSOl．
Forembedded systems′SOmefunctionalityis provided byhardwareelements′

WhichshouldaJsobecapturedinthefunctionaImodel．Hence′intheextended
USeH：aSe mOdef，a uSe−CaSe Can rePreSentS either hardware or software

functiona＝ty．Consequently′We need toclassifyand distinguish twotypesof
functionaIitiesbyusingUMLextensionmechanisms．
ln theextended usecase model，SeCOndary usecasesthatareinvoked bYthe
Primary use cases through≪include≫

and≪exte■．d≫

relationship．A

thoroughidentificationoftheprimaryandsecondaryusecaseswiHresuttinthe
COmPLeteidentificationofaHthefunctiona価esthatshouldbeprovidedbythetargetembeddedsystem．

□

RepresentingStructuraJViewClassdiagram capturesthestructuralelementoftheSOL．［ntheextend UML

PrOfile′bothhardwareandsoftwareelementsaremodeledasobjects．Asetof
StereOtyPeSandtaggedvaluescanbepre−definedtoeasetheprocesstomodel
embeddedsystemrequirements．Relationshipssuchasassociation′COmPOSition′

dependencyandinheritanceshouldalsobeappHedbetween hardwareobject
andsoftwareobject．
With thecomponentdiagram，the unitof

package

WiH beusefultomodeIa

COmPOSite container ofembedded system．As a grouping unit′the container

typicallycontainsasetofrelatedhardwareobjectsandso托wareobjects．

DeploYment diagram can be used to denote the phYSicaf characteristics ofdeproyed elements ofembedded sYStem．A nodewoutd consistofpackages′
and the connection among nodes would be a bus or a hardware−IeveHnter−

PrOCeSSChannel．

口RepresentingDynamic（Behavirol）View

The dynamic view of the embedded system models theinteraction among
diverseelementswhichcanbehardwareorso托wareobject5．5equencediagram

Can be drawn with hardware objects as wellas software objectsin order toShow theinteraction among the various objects．The UML profiIe shouId

42

﹁ト弓

WorkshopReport

SEAMAILVol．14，No．5

l WorkshopReportprovidewaYStOdifferentiatetheinteractionbetweensoftwareelementsandtheinteraction between softwareobjectand hardware object．For theinteraction

betweensoftwareelements′Object−Orientedmessageisthemostcommonform
ofinteraction．Fortheinteractionbetweensoftwareobjectandhardwareobject′
therecan beseveraJdifferentformsofinteractions．Hence′Withtheextended

mechanismsofUMLprofHe′WeShouldbeabletoexpressthecorrectformof
interaction．

C］RepresentingVariability′VariationPointsandVariants
Product一日neengineeringis mainlyforinter−Organizationalreuse′ratherthan
intra−Organizational／project reuse・Hence′itis essential to model thecommonaLityandvariabi＝tY（C＆V）thetargetdomain・UMLdoesnotprovide
constructstoexpresstheC＆V・TheUMLprofHeshouFdinctudeconstructsto
denotethevariationpointsandvariants・AIso，thecomponentswithvariabilityinaproduct−lineneedtobecustomized
for each product−line member・Hence′itis essential to provide thecustomizationmechanismsandnotations．

ロ

RepresentingExtra−FunctionaNiew
For embedded systems′eXtra−functionalrequirementis asimportantas thefunctionalrequirement・Forexample′mOStOftheembeddedsystemsrequirethe
hardorsoftrea］timeprocessing・Thisrelatestotheperformancerequirement′

morespecificaHyresponsetime・Hence′adesignmodelwiththeUMLprofile
shoulddenotetheextra−functionalrequlrement．

3．2・4

口

Topic糾・Self−Adaptive／ContextawareSOftware

Motivationo EmbeddedsoftwareenvironmentsaregettingmorecomplicatednowadaYS
duetoincreaseddemandsonsoftwarefunctionalitiesandmoreinteractions
amongsystems・Forexample′mOrethan80％ofautomobiIecontrolunits functionaLities are done by software andits roleisincreasing・

Furthermore′thatsoftwareareinteractingwithotherssuchasmaintenancemanagementsystemandnetworkingsYStem・Thatleadsmoreexpectedor
unexpectedenvironmentsandfunctionaJchangesduringruntime・Todeal
withthesechanges′SOftwareneedstobeadaptableduringruntime・ロ

DefinitionofSeIf−AdaptiveSoftwareo（SeIOadaptivesoftwareeva−uatesandmodifiesitsownbehavior（bYitse晰nresponsetochangesinitsoperatingenvironmentbYend−USerinput′eXternal

hardwaredevicesandsensor′OrPrOgraminstrumentationtoaccomplishingwhat the softwareisintended to do′Or When better functiona＝ty or

Performanceispossible・43

WorkshopReport□

SEAMAILVbl．14，No．5

Deve．OpmentofseIfadaptivesoftwareraisesaJotofresearchissuesincluding

O Howcanwegetinformationfromrunningsoftware？

O Howcanwemakeajudgmentwhatwentwrong？
O Howcanweadapt〜
O HowcanweverifytheresuItofadaptation？

o webservicesforembeddedsoftware。Thisisnoton■yissueofwebserviceslitisanissueofinternetandembedded

systems・Traditionally′embeddedsystemsarestand−aIonesystemsbuttheYareconnectedthroughinternetand′furthermore′Web・□lssueso Howtoconfirmconsistencyortrustotherservicesontheweb？
O Howtomeetthetimingconstraints？

O Do we need anY Other mark uplanguage for web based embedded
software？

o whatarethemostapp日cabledomainsforwebbasedembeddedsoftware？

3・2・5

Topic＃5・WebServicesfbrEmbeddcdSoftwareE］CanweapplyWebServicestoEmbeddedSystems？Andisiteffective？
O Thisistheprimeissue・ロ□

HowcanweappLyServiceOrientedArchitecture（SOA）toembeddedsystems？

TheWebServicesareunreasonableforstrictreal−timeandconsistencysYStemS′

becauseofusingInternetandparsingXML・□ロ

ttisaverYdifficuLttrade−Off

How can we speci〜Specifications and verify coordination between each
SerVice〜E）Whichmeasuresand／ortooIsareusefulforWebServicesdevelopment？

3．2．6
ロ

Topic＃6・Verification＆Validation
Howcanwehandlenonfunctionalrequirements！
O RealTime′ReliabiJity′Performance′Safety′Security・・□

Wew川overcomecrosscompileEnvironments／HowcanweSimulatethereaJ

environments

O AlmostimpossibIetotestwithouthardwareportingE）Howcanwemakesystematictestingprocessinembeddedsystem？

44

WorkshopReport○

SEAMAILVol．14，No．5○rganizingtheindependentSQATeam

E］Howcanwesetupthesoftwarequa＝tystandard？
O Findingasoftwarequalitycharacters＆metrics

ロ

How can we make a software checklist for formalinspectionin embedded
SYStem？

E）Dynamicconfigurationabilityrequirescodificationandrun−timeappIicationof

designknowledge

O HowtoidentifYCOnteXtChanges

o Howtofindthebestmethodtoaddressthecontextchanges
O HowtoseamJessIYreCOnfigurethesystem□

Verificationofsafety／securitycriticalsYStemSo FormaHzationandverificationofassetswithbuHt−invariationpoints

O VerificationofappIicationswithinstantiatedvariationpoints
Oldentificationoffeatureinteractionproblems

O VerificationofappIicationsthataredynamicallyreconfigured
ロ

Agenttechnology／AltechnoLogies

V＆VSubjects

Rigorousness●reVleWdomain・Walkthrough・functionrequirement・behavior

・inspection

SPeCification・COnStrai・Simulation

design・teStingnt

COde

・mOdelchecking

TheoreticalModels

・Pr00fFigure3−1・AgentTechnologyandAltechnology

3・2・7

ロ

Topic＃7・CharaCteristicsofEmbeddedSoftware

EmbeddedsYStemuSuallyconsistsofembeddedandreaトtime・
O Theyaredifferent・□

Real−timerequirementrelatestothenaturallow／phenomena・

E）Embeddedconstrainofprogrammingis

tight then assumption usuaHY uSedin software development may not
appropriate．

O Constraints′LimitedResource

45

WorkshopReport

SEAMAILVbl．14，No．5

E］Software

O ManYdeviceswhichshouIdbecontroHed（1／○）exist．
O Time（hardorsoftreaトtime）descriptionisessential．

0

Designoftaskishardwork＞□

Tosomeextent′triaJ・anderror

DevelopIng

O Hardtodebug
O SmaHnumberofutilitylibrary
O Usua＝Y，thefunctionalityofOSispoorandinstable．

O Havetoknowaboutmanyl／Oprotocols

ロTo embed executab］e program andinformation constructinto smaH memorY

box．
O Let

ロ

smakevirtualmemorysYStem．

Toembedexecutionfunctionalityintonarrowtimezone

O Humandoesn□

trecognizedelay

ToembedaHadditionalcapabHtytofixhardwareprobIemintoproject
O Replaceit．

□

Strong preference to decrease re50urCe rather thanincreasing goodunderstanding

O ContinuousefforttoseparatedomainsE）operationtothehardwareismostiYCOnSideredindesigner

smind

O Human／actoriscenterofdevelopment．

□lf sYStem does not satisfy the requirement′Penaltyis high and rise垂型

PrOblem．
□

Complexityinfunctionandinsize

E］Timeliness

O Evenwithinfinitelyfastcomputers′embeddedsoftwarewouIdst州haveto
dealwith time because the physicaJ processes，With whichitinteracts′

evoIveovertime□

Concurrency
O EmbeddedsystemsrarelyinteractwithonIYaSinglephysicalprocess．

O They must simultaneously react to stimulus from a network and from a
Varietyofsensors′andatthesametime′retaintimelYCOntrOloveractuators．

46

SEAMAILVol．14，No．5

WorkshopReport

O Devicesoperateinparallel．

□

Liveness

O tn embedded syStemS，PrOgramS muSt nOt terminate or block waitingfor
eventsthatwjllneveroccur．

OInembeddedcomputing′terminatingprogramsaredefective．
OltneedshighreliabHityandsafety．

E］lnterfaces

O Most widely applied component technologY based oninterfacesis
PrOCedures．
O Procedures are finite computations that take pre−defined arguments and

PrOducefinalresults．

O But′Proceduresarepoormatchformanyembeddedsystemproblems・
O For embedded so在ware to benefit from a component technology′thatcomponenttechnologywHhavetoincludedynamicpropertiesininterface
definitions．

ロ

Heterogeneity

O EmbeddedsystemsmixheterogeneouseventhandHngstyles・
O Theyinteract with events occurringirregularIyin time（aJarms′

uSercommands′SenSOrtriggers，etC．）andregularIyintime（SamPledsensordata
andactuatorcontroIsignaJs）．

O FaciHtiestointeractwithspecialpurposehardware．

□

Reactiv吋

O Reactivesystemsarethosethatreactcontinuouslytotheirenvironm6ntat
thespeedofenvironment．
O Reactivesystemshavereaトtimeconstraints′andarefrequentlysafety−Critical
tothepointthatfaHurescouIdresultinlossofhumanlife・

O ReactivesystemstypicaHYdonotterminate・

E］Lowmanufacturingcost。ApplicationandDomajnSpecificE）Distributedロ

OperateinharshenvironmentE］Mustmeethighintegrityqualityattributerequirements□

SmaHsizeandweight47

WorkshopReport

□

3・2・8

SEAMAILVol．14，No．5

Power concern

Topic＃8・FutureCollaboration□

EstabHshingareSearChcommunitywithparticipantsロ

Candidate Names

O ProductLneEngineeringforEmbeddedSoftwareDevelopment
O SoftwareEngineeringforEmbeddedSoftware
El Activities

O Workshops

O Websiteforthecommunity
O News′Q＆A′BBS′etC・

O ExchangeofResearchResultsandTechnicalMaterials
O SeekingResearchFund

O ExtendedMaiJingList
O jointlypublishingbooksandtrainingmaterials・□Adion tist

O Settingupawebsite（Prof．Kang′Mr・Futagami）＞

q＆AGroups

O MaintainingamailingHst（Prof・Kan由O RepositoryofTechnica＝Materials（Prof・Kim）
0）OintLypublishingbooksandtrainingmateriaIs・

00rganizinglstWorkshoponProductLineEngineering＞

CanbecombinedwithothereventsuchasAPSEC．

48

CallforParticipation

SEAMAILVol．14，No．5

DW2005

デザインワークショップ

DW2005「組み込みソフトウエア仕様検証技術の最新動向一一PROMELA／SPINを用いて」

主催：ソフトウエア技術者協会
異なるプロセスがあり，それぞれが通信することで構成されるシステムを如何に設計するかは，昔から議論されてきた話題です．但し，かつては一部の人たちの知識や経験だったものが，現在では多くのソフトウェア設計者が身に付けておくべき技術となりました．組込みシステムや，分散システムが一般化したことが理由として挙げられます．
今回は，＄旦！哩というLTLとCSPに従った模型検査が可能なツールを利用することで，日頃の我々の設計作業の中で生かし，より安全で信頼性の高いシステムを作るための手段と方法について議論したいと思います．

課題となる問題を用意して、実際に仕様を記述し、SPINで仕様のチェックするという実習を行います．
できるかぎり，SPINのインストールされたPCをご持参下さい．

日時：2005年2月24日−26日（2泊3日）土曜日昼解散
場所：ウェルハートピア熱海（厚生年金ハートピア熱海）

http：／／www．kjp．or，jp／hp＿99／

定員：15名

参加費：
学生

25000円

SEA会員

30000円

SEA賛助会員

35000円

一般

40000円49

CallforParticipation

SEAMAILVol．14，No．5

申し込み方法以下の申し込み書に記入の上・emai．でSea＠sea・Or・jpまでお送りください．折り返し，請求書をお送りしますので・1ケ月以内に指定の銀行まで振り込みをお願いします．
【申込書】デザインワークショップDW2005参加申込書

氏名：
ふりがな：

種別：
□SEA会員（No．

）□SEAシルバー会員（No． ）所属会社（学校）名：
部門＆役職：
住所
TEL（内線）：
FAX：
E−MAIL：

なお・課題を事前に（お好みの方法で）記述するようにして下さい．

50

CallforParticipation

SEAMAILⅥ）1．14，No．5

DW2005のための問題（山崎利治さん作成）

ご利用に際してあなたの物置番号は125です．いま扉は閉まっていて施錠してあります（施錠灯が点いています）

0『−
雛鍵野

1

瀧奉筍

2

3

4

5

6

7

8

9

C

O

L

図1．物置
物置番号の書かれた物置の扉にはパネルがあり，そこに，施錠灯，0から9までの押ボタン，CLの押ボタン，
10進数字4桁の液晶表示窓，90度回転する取っ手が付いています．

扉の開けかた（1）数字ボタンを1234（施錠鍵といいます）と左から順に押してください．

（2）押した数字を表示窓で確認してください．
（3）それが1234であれば施錠灯が消えます（開錠）．
（4）そこで扉の取手を時計回りに90度廻して手前に引けば扉が開きます．
（5）数字ボタンを押し間遭えたときは，Cボタンをおして，始からやり直してください（Cボタンを押すと表示窓の数字が消えます）．

51

SEAMAILVbl．14，No．5

CallforParticipation

扉の閉めかたと施錠（1）扉を閉め取手を逆時計回りに90度廻します（機械的な施錠）．
（2）Lボタンを押します（電子的な施錠）．
（3）ここで施錠灯が点きます（直前に扉を開けたときのあるいは，次項によって愛更した鍵による施錠），（4）その後は開錠手続きをしない限り，取手を廻して引いても扉は開かないはずです．

鍵の変えかた
施錠灯が消えているときに，つぎのようにして好みの鍵にすることができます．

（1）数字ボタンを4回押す．この4数字が新しい施錠鍵になりますので必ず表示窓で確認の上ご
記憶ください．

（2）ついでLボタンを押します．そこで鍵が登録され，表示窓の数字が消えます．
以

52

上

SEAMAILVol．14，No．5

CallforPapers

論文／報告募集
ソフトウェア・シンポジウム2005
http：／／ss2005j寧桓t二aQJp／

2005年6月8日（水）〜10日（金）富山国際会議場http：／／www．ticc．cojp／

主催：ソフトウェア技術者協会
協賛（予定含む）＝日本ソフトウェア科学会，情報処理学会電子情報通信学会ソフトウェアサイエンス研究会，
情報サービス産業協会，富山県情報産業協会，富山県総合情報センター
後援：富山県，富山市

ソフトウェア・シンポジウムは，ソフトウェア技術に関わるさまざまな人々（技術者，研究者，教育者，企業人学生，等々）が一同に集い，発表や議論を通じて互いの経験や研究成果を共有することを目的に，毎年日本各所で開催されています．初めて
1980年に開催されたこのシンポジウムも，来年で25回目（四半世紀）を迎えることとな

り，開催会場を「立山あおぐ特等席」＠富山市に用意することができました・
今回は「節目となる四半世紀」をテーマに，例年どおりの研究論文／経験論文／事例報
告の他にショートペーパーという投稿枠も設け，ソフトウェア技術の未来を予見させるような論文や報告を期待しています．未来を予見するとは，過去の実績を踏まえた上で大胆な一歩を踏み出すことです．ダイナミックな技術変化を積極的に捕らえ，皆さんと共に明日のソフトウェア技術の姿を議論出来ればと考えております．
ここにソフトウェア・シンポジウムの原点となる第1回目のProceedings巻頭の言葉を引用し，論文募集のメッセージとさせて頂きたいと思います．皆さまの積極的なご応募を心よりお待ちしております．

「（前略）学問的なそれ等の成果を，現実の仕事に如何に導入するか．そしてその結果が再び学問的な場でいかに採り上げられるかという事も欠くことの出来ない巡路である．ソフト協の今回行うシンポジウムは学会の二番煎じではない．学会の縮刷版でもない．全く別の視点からの問題の議
論こそ，このシンポジウムに期待する処である．会員各位の御賛同を願う
こと切である．」（社）ソフトウェア産業振興協会会長服部正（1980年12月当時）

主要スケジュール
．投稿締切：2005年2月28日（締切は決して延長されません）●採否通知：2005年3月28日．最終原稿締切：2005年4月25日

対象分野募集する論文／報告として以下の分野を想定していますが，ソフトウェア技術に関連していれば他の分野でも構いません．

■要求工学■品質管理／標準化

遭プログラミング技法｛セキュリティ¶開発ツール／環境■分析／設計／開発方法論

53

SEAMAlLⅥ）1．14，No．5

Call丘）rPapers

JWeb情報システム／Webサービス■保守／リエンジニアリング『組み込みシステム■ビジネスプロセス／ドメイン分■構成管理析■再利用技術／コンポーネント眞オブジェクト指向技術■オープンソース開発■メトリクス■開発プロセス／プロセス改善■教育支援技術

THW／SWコデザイン

1テスト技法■形式手法■システム検証

技法

投稿要領
研究論文，経験論文，ショートペーパー，事例報告の4種類を募集します．ショートペーパーは萌芽的な研究や遂行中の実践・事例の報告を目的としたものです．下記

URLの要領で作成し，カバーシートと合わせて，電子メールでss2005−
submit句垂主二由旦宛てに2005年2月28日（必着）までにお送りください．投稿を確認するメールが返信されます．返信がない場合には箪些鱒−inq亀旦垣握加までお問合せく
ださい．

b旦幽担旦幽j幽夏
投稿された論文／報告はプログラム委員会で査読を行い，採否を決定します．採否審
査結果は3月28日までに応募者全員に電子メールで通知します．また，採録された論
文／報告について，研究論文・経験論文から最優秀論文を，全登壇者から最優秀発
表をそれぞれ選定し，シンポジウム最終日に表彰します．
応募論文／報告は未発表のものに限ります．他への重複投稿もご遠慮ください．論文は原則として日本語で執筆して下さい．例外として英文も受付けますが，当日の発表
は日本語に限ります．採録された論文／報告は，論文集（紙，CD−ROM）に掲載される
ほか，インターネットで公開される場合があります．

研究論文
新規性や独創性のある理論，手法，ツールなどを提案する論文です．A4版5ページ
以上10ページ以内とします．研究論文は研究の新規性や独自性を重視して審査します．当日は発表に20分，質疑討論に10分が割り当てられます．

経験論文
既知の理論，手法，ツールなどの適用経験を元に得られた，その利息欠点導入障壁などの知見を述べる論文です．ソフトウェア技術に関する団体や活動の運営経験を元に得られた知見を述べる論文も歓迎します．A4版5ページ以上10ページ以内とします．経験論文は知見の有用性を重視して審査します．当日の時間枠は研究論文と同様です．
ショートペーパー

斬新なアイデアによる進展中の研究や，小規模な適用経験や運営経験などをA4版4ページ以内で述べる論文です．研究と経験の区別を設けて通常の論文と同様に審査しますが，加えて萌芽性や速報性が求められます．当日は発表に10分，質疑討論に10分が割り当てられます．

54CallforPapers

SEAMAILVol．14，No．5

事例報告
経験論文と同じく適用経験や運営経験による知見を報告するものです．文書としてまとめられない，あるいは公開できない知見を報告いただくために，要旨（A4版1ページ）と発表スライド原稿（10枚程度）だけで審査します．スライド原稿に要点などを注記していただけると，査読者の理解が深まります．経験論文と同様に知見の有用性を重視して審査します．当日は発表に15分，質疑討論に5分が割り当てられます．

シンポジウムスタッフ
実行委員長
近藤康二（ソニー）
実行副委員長田中一夫（JF汀S）

プログラム委員長
菅原耕一（富士フイルムソフトウエア），藤枝和宏（JAIST）
プログラム副委員長

鈴木郁子（シャープ）
プログラム委員

荒木啓二郎（九州大），飯田周作（専修大），伊藤昌夫（NIL），今泉貴史（千葉大），臼井義比古（環境システム研究所），小笠原秀人（東芝），落水浩一郎（JAIST），川井奈央（IPA），菊池豊（高知工科大），蔵川圭（NAIST），小池太（日立），権藤克彦（東工大），阪井誠（SRA−KTL，EASE），酒匂寛（Designers，Den），佐原伸（JFITS），新谷勝利（IPA），鈴木裕信（鈴木裕信事務所），高井正三（富山大），冨永和人（東京工科大），冨山宏之（名古屋大），豊永正人（日立ソフト），中野秀男（大阪市大），西康暗く電通大），野呂昌満（南山大），畑田稔（富山県立大），林香（SRA），東田雅宏（PFU），藤野晃延（InArcadja），二上貴夫（東陽テクニカ），古木良子（オープンテクノロジーズ），堀田文明（JAIST），

松下誠（阪大），松田充弘（日立国際電気），水野修（阪大），山本晋一郎（愛知県立大），鷲崎弘宜（NII）
ローカルアレンジメント
新森昭宏（INTECWebandGenomeInformatics）

事務局
岸田孝一（SRA−KTL），中島千代子（SEA）

問合せ先
SS2005−inqqajstACJp

55

CallforParticipation

SEA

SEAMAILVol・14，No・5

FORUM（January，2005）

第13回SEA新春教育フォーラム
教育工学の現状を切る〜教育は理論と実践を尊重しているか〜

参加者募集
sEA恒例の新春教育Forumを下記の要領で開催します．SEAの教育分科会（SIGEDU）では，過去18年間教育工学について多くの議論を繰り返して，効果的な教育を効率的に実践するための情報交換をしています・
2005年は終戦後60年ですが，日本の教員免許試験に出題される教育原理は戦前のものが大半です・比較的新しい教育工学を導入している組織であっても，バブル経済中頃の30年前ぐらいの状況にとどまっています・教育分野の古きやブーム
を，理論と実践の両方を重視する観点で議論します．
ふるってご参加ください．
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ 開催要領 書＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

1．日時：2005年1月28日（金）13：30〜17：00

2．場所：東京都南部労政会館（東京・品川区大崎ト1ト1ゲートシティ大崎ウエストタワー2F）
地図：http：〟www．seajp／Maps／NanbuRousei・htm1

3．実施内容：
バネラ

森和夫

東京農工大学：「職業としての大学教員を分析する」

新井吾朗 職業能力開発総合大学校：「公共職業能力開発を切る」
中原淳
メディア教育開発センター：「企業内人材開発HRを切る」
池田真司 リコーテクノシステムズ：「教育体系開発ID手法を切る」
甲圭太
長岡技術科学大学：「計算機援用教育CBTを切る」
コーディネータ

米島博司

NECテレネットワークス

都合により，バネラやバネラのスピーチ内容の変更がありえます．
4，スケジュール：13：00、13：30

受付

13：30、14：45

バネラ紹介と各バネラのポジションスピーチ

14：45〜15：00

コーヒーブレイク（ご歓談の時間）

15：00、16：45

全体討論

16：45〜17：00

エンディング詳細については，実行委員長・君島浩（mso−Ced＠icjmsdf．gojp）までお問い合わせください・

5．参加費：SEA正会員・賛助会員および学生：1，000円，一般3，000円
6．申込み方法：下の申込用耗に必要事項をご記入の上，SEA事務局までE−Mailでお申込みください・なお，参加費は

当日会場受付にてお支払いください（領収書を発行します）．申込受付後のキャンセルは原則としてお断りします・
定員は45名（先着順）

申込み宛先：ソフトウェア技術者協会（SEA）
E−Mai1：Sea＠sea．orjp Fax：03−3356−1072URL：http：〟www・SeaJp

SEA・Forum（Jan．2005）参加申込

氏名（ふりがな）：

会社名：

E−Mail：）□賛助会員（No．

種別（該当欄にチェック）：□正会員（No．
56）□一般 □学生

名

ソフトウ土7技術者協会〒160東京都薪膚区四谷3−12丸正ビル5F¶≡」03−認詭−10Trl執X．03−3356−1072