トピックス

  
投稿日時 2011-11-15 03:55:57 (4031 ヒット)

11月9日に第2回研究会を開催しました.会員29名(ウェブ参加2名を含む)が参加しました.概要は次のとおりです.

日時:2011年11月9日(水)13:00-18:00

場所:名古屋大学 東山キャンパス 情報基盤センター 会議室

共催:名古屋大学 大学院情報科学研究科 附属組込みシステム研究センター

長野工業高等専門学校 地域共同テクノセンター 寄附研究部門 制御システム開発研究部門(ミマキエンジニアリング)

--------------------------------------------------------------------------

1.発表
  「開発文書品質の研究と課題-長野高専寄附研究部門での取組み-」
  背景説明:山本雅基(名古屋大学),塩谷敦子(イオタクラフト)
  発表:藤田悠(長野工業高等専門学校)
  
ASDoQの代表幹事である山本雅基と幹事の塩谷敦子が,開発文書との関わり・ASDoQ設立に至る経緯と,開発文書の課題を,それぞれ発表しました.次に,ASDoQ幹事・事務局長の藤田悠が,文書診断に関する研究と教育について発表しました.
 
 
2.作業部会の取組紹介
現在,活動している3部会から,状況報告がありました.そして,それぞれの活動内容に関する質疑と討議を行いました.
 
ロードマップ部会
 開発文書品質の研究課題の整理と研究のロードマップ策定に向けた取り組みの状況を報告しました.
 
 
 
用語定義部会
 部会で取り組む内容や活動の進め方を報告しました.部会では,(1)ASDoQで用いる用語の定義,(2)文書技術の整理,(3)定義すべき用語の選定指針と定義指針の作成,の3項目に取り組む予定です.状況報告の後,参加者全員で定義すべき用語の洗い出しを進める中で,作業方法に関する討議を行いました.
 
人材育成部会
 部会活動の目的と目標を発表しました.主な活動として,具体的な製品を想定した開発文書を作成し,開発文書品質を模索しながら,文書を修正し改訂していく活動を行う予定です.開発文書の題材に関して討議しました.
また,ある会員から,所属する企業での状況とそこで進められている開発文書品質に関する取り組みの紹介がありました.そして,課題解決の方法が,ASDoQが進める課題に適合しており,それを部会活動の中で進めていける旨の確認がなされました.


投稿日時 2011-09-20 09:39:27 (5142 ヒット)

SEA名古屋, ソフトウェア・メインテナンス研究会(SERC)ジョイントフォーラムにて,ASDoQの藤田事務局長が,自身のシステム開発文書に関する研究内容の講演とASDoQの紹介を行いました.

SEA名古屋, ソフトウェア・メインテナンス研究会(SERC)ジョイントフォーラム概要
http://www.smsg.or.jp/forum110826.htm

テーマ:「これからのソフトウェア開発」
開催日時:2011年8月26日(金) 13:30 - 16:50
開催場所:ウィルあいち 2F セミナールーム5 (名古屋市)
 

当日の資料

講演資料:「システム開発文書の課題と展望  ―文書診断法を活用した 開発文書の品質向上の取り組みを通して―」(pdf)


実施報告

「システム開発文書の課題と展望
-文書診断法を活用した開発文書の品質向上の取り組みを通して-」

という題目で,藤田が講演をしました.
藤田自身が行っている実開発文書を対象にした文書診断法とその結果を活用した技術者教育の話,
さらに,組込みシステムを取り巻く現状からみた開発文書の必要性を踏まえて,本研究会の紹介を行いました.

フォーラムへの参加者は11名と多くはありませんでしたが,
ディスカッションでは引きも切らずに質問があがりました.
藤田自身の研究と,ASDoQの進め方などを考えるきっかけとして
有意義な発表の機会でした.

以下に,私の発表にて挙げられた主な討議事項と,
それに対して答えた内容を紹介します(報告のための補足を含む).

■藤田の研究に関する質問
(Q1) 対象としている文書はどのような種類の文書か?
(A1)  どの開発工程の文書であるかは限定していない.
   現状では,要求定義書や設計書に当たる文書を診断する機会が多い.

(Q2) IEEE830やISO9126などの既存の特性ではなく,新しく特性を考える理由は何か?
(A2)  ISO9126はソフトウェアの内部品質,外部品質などを測る特性として提示されている.
   この特性は,ソフトウェアの視点からみた特性であると考えている.
   それを開発文書の品質としてそのまま適用することが適切かどうかは疑問である. 
   IEEE830は,ソフトウェア要求仕様書が持つべき特性などを示しており,
   参照すべき規格であることを認識している.
   しかし,ここで述べられている特性を満たす仕様書にするために,
   テンプレートと,テンプレートのそれぞれに書くべきことは提案されているが,
   どのように書けばよいかについては,述べられていない.
    したがって,これらの規格があることは踏まえておきたい.
   そのうえで,文書の視点からみた特性を設けることで,
   文書における改善すべき点などが把握しやすくなるのではないかと考えている.
   その特性に,肉付けるもしくは,ひもづけるなどの形で,
   それぞれのドメインの特徴やソフトウェアの品質特性などと関連付けたい.

(Q3) どれだけ鍛錬することで文書診断ができるようになるのか?
(A3)  現在文書診断を行っている2名についても,経験に差がある.
   その差を埋めるために必要な年数などはその人の能力にもよるだろうから
   何年経験を積めばよいかについては明確にはわからない.
   しかし,その差を埋めるために,文書診断者のスキルを向上させる施策をとることで,
   ある範囲の問題を検出する診断ができるようになると考えている.
   どの程度診断ができるかを明らかにするためにも,文書の品質を定義することで,
   ある一定の品質を診断できる診断者であると
   言及できるようになるのではないかと考えている.

(Q4) 診断者ごとの診断結果の違いに対する対策などはあるか?
(A4) 現在,診断者のバラつきを低減させるための方法として,
   診断の粒度をそろえる試みを行っている.
   問題であると判断した文言に感覚的な語彙を用いずに,
   何をどのように認識したかを明示させるようにして,
   診断の方法を細かく分析している.

■研究会の活動に関する質問
(Q5) 研究の対象とする文書のドメインはどのように設定するか?絞って行うのか?
(A5) 文書を書く時に,何をどのように書くかと考えた時,
   何を書くかについては,ドメインごとによる違いが比較的多く出てくるかもしれない.
   他方,どのように書くかについては,ドメインに関わりなく,
   共通する部分が多いと考えている.
   研究会の参加者それぞれが持つドメインの視点から考えることで,
   ドメインに共通する部分が明らかになるのではないかと考えている.
   その共通する部分を具体的に検討する時に,
   ある特定のドメインを取り上げてすすめることはあるかもしれない.
   その結果を参考にして様々なドメインに展開できるのではないかと考えている.

 

他の2件の発表を行った石川雅彦さん(SRA)は,
当研究会の第1回準備会議にご参加頂いております.
その発表も興味深い内容でした.
特に「SERC-B報告:研究概要と保守開発のための情報の残し方に関する困難さについて」
においては,『100,000年後の安全』
http://www.uplink.co.jp/100000/
という映画を事例にあげて問題提起されていました.
通常考える時間と懸け離れた,長い時間の事例ではありますが,
時間を超えて情報を伝える方法や,
根本として解決すべき問題のとらえ方を考えさせられました.

 

 

(藤田)


参加報告

SEA/SERCジョイントフォーラム 「これからのソフトウェア開発」 参加報告(pdf) (山本佳)

 


投稿日時 2011-09-11 22:39:35 (4181 ヒット)

SWEST13 (組込みシステム技術に関するサマーワークショップ) に,ASDoQ運営委員を含む会員8名が参加し,ASDoQ紹介のポスター展示・チュートリアル・パネルディスカッションを行いました.

SWEST13概要  http://www.ertl.jp/SWEST/
Summer Workshop on Embedded System Technologies (SWEST)13
「組込みシステム技術に関するサマーワークショップ」

テーマ:「議論しよう!今、エンジニアができることを。」
開催日程:2011年9月1日(木)~2日(金)
開催場所:下呂温泉 水明館(岐阜県下呂市)

当日のASDoQ資料

ポスター資料: 「システム開発文書品質研究会(ASDoQ(アスドック)) へのお誘い」(pdf)

チュートリアル資料:「誰がために開発文書を書く」(pdf)

パネルディスカッション資料:「新しい開発文書の時代を迎えて」(pdf)


ポスター展示

第1日目(9/1)14:50~17:30のプロジェクトアップデート・ ポスター・デモ発表  にてASDoQの紹介ポスターを展示しました.

ASDoQの存在と活動を広報するため,運営の概要と活動計画をポスターにて展示しました.
ポスターの前で立ち止まってご覧になっている方の中には,「このセッションのために今回参加しました.明日のチュートリアルを楽しみにしています」と言って下さる方もいらっしゃいました.また,ご自身の職場で開発文書に関して苦労されている点などを話され,「他の会社はどうしているんだろう」と,なんらかの課題解決のきっかけを求めておられる様子の方も,ASDoQに興味を示していただいたようでした.

 
 

セッションS45-d 「新しい開発文書の時代を迎えて」

第2日目(9/2)13:00~15:50のセッション(S45)にて,開発文書に関するチュートリアルとパネルディスカッションを行いました.

会場には,20名強(講師・パネラを除く)の方が聴講されました.途中から入ってこられ,立ったままで聴かれている方も数名いらっしゃいました.

 

チュートリアル:「誰がために開発文書を書く」

講師:山本 雅基 (名古屋大学)
コーディネータ:栗田 太郎 (フェリカネットワークス)

ASDoQの山本代表幹事が,開発文書を能動的に書くことへの動機付けとして,チュートリアルの講師を務めました.

 

 パネルディスカッション:「開発文書と私」

コーディネータ:栗田 太郎 (フェリカネットワークス)
パネラ:              坂本 佳史 (日本IBM)
                           塩谷 敦子 (イオタクラフト)
                           清水 吉男 (システムクリエイツ)
                           杉本 明加 (富士設備工業)
                           藤田 悠 (長野高専)
                           森川 聡久 (ヴィッツ)
                           山本 雅基 (名古屋大学)

 パネルディスカッションでは,まず,コーディネータと各パネラが,自己紹介と「私にとっての開発文書」を紹介をしました.そして,各パネラから,次の項目に関する経験や意見を発表しました.

・開発文書にまつわる思い出
・問題を含む文書
・良い開発文書とその工夫

会場からは,各パネラの発表に対して質問をいただきました.そして,その質問から他のパネラや参加者の意見に発展する場面も,時折ありました.

パネラも会場の参加者も,まだまだ言い足りないこと,問題点として投げかけたいことなど,話題は尽きない,さらにこれから議論を深めたい,という雰囲気になってきたところで,終了の時間になりました.
「つづきは,ぜひASDoQが開催する研究会の中で,行いましょう」というコーディネータの言葉で,セッションを閉じました.

 ご参加くださった方々,ありがとうございました.

 


報告者所感:

組込み技術者が集まるワークショップということで,この「開発文書」に関するテーマは,他のセッションに対して少し異質のものになるだろうと,SWESTに参加する前の私は,そう思っていました.特定の技術に対するスキルやテクニックを得るためのチュートリアル,知識を吸収したり技術的な動向を把握するためのセッションが多い中で,「開発文書をとらえ直す」という意味合いを持つこのセッションには,おそらくなんらかの開発文書に関する問題や課題を持って初めて参加の興味につながるのだろうと,私は考えていました.そして,いったいどのくらいの人が,興味を示すだろうか,不安でした.

ところが,ポジションペーパーに書かれた何人かの開発文書に関する話題や,前日のポスター展示で受けた印象から,多くの人が開発文書のテーマに関して興味を示されていることを知りました.そして,チュートリアルやパネルディスカッションでも,講師やパネラが投げかけた(つもりの),開発文書が抱えるさまざまな課題に対して,常日頃,同様に問題意識を持っている方が,大勢いらっしゃることを実感しました.さらに,自らの問題に対して,その解決や改善のきっかけを求めているということも,あらためて感じました.

そんな方々の思いをASDoQへの期待へと向かわせることができるなら,会の大きな励みになります.開発文書に関する問題点,課題,疑問を持つ人たちが集い,みんなでの活動が,それぞれの解決の糸口となるような,ASDoQがそんな会になればと願っています.

そして,誰がためにASDoQに興味を示すや...ご自身が持つ課題解決のための積極的な参加をお待ちしています(塩谷).


« 1 ... 21 22 23 (24) 25 26 »

メニュー

サイト内検索

ログイン

ユーザ名:

パスワード:

次回からIDの入力を省略



パスワード紛失