ソフトウェア設計・開発教育のためのインスペクション支援システムに蓄積されたコメントの分析
6
0
0
全文
(2) 1 はじめに 情報技術の発展に伴い、ソフトウェア開発に対 する要求が高まってきており、高度な技術を有す る人材育成が求められてきている。このような背 景から、大学教育にも質的な転換が迫られてきて いる。実社会で行われているソフトウェア開発は 一般に、複数人により構成されるプロジェクトと いう形態で行われている。それにもかかわらず、 大学等の教育現場において、プロジェクト形式で のソフトウェアシステムの実践的な設計・開発教 育の機会にめぐまれていないというのが現状であ る[7,10]。著者らは、1997 年度より大学において ソフトウェアシステムの設計・開発教育をグルー プ演習形式で行っている[4]。この授業では、学習 者の作業負荷は大きく[1]、 効果的で効率的な学習 支援が必要不可欠である。そこで、著者らは本教 育を支援するシステムの開発を行ってきた[3]。 開発途中の成果が目に見えにくいという性質を 有するソフトウェアシステムを複数人により共同 で設計・開発していく場合、プロジェクト内での コミュニケーションを円滑にし、情報や認識を共 有することがプロジェクトの成功に大きく関わっ てくる。 特に、 開発するソフトウェアの概念設計、 開発内容、実現方式等について話合い、決定を行 う上流工程におけるコミュニケーションが重要と なる。システム開発を初めて経験する大学生にこ のことを認識させ、そして、それを支援するプロ セスを構築し、そのプロセスに基づく支援システ ムを提供することが重要である。著者らのこれま での教育実践経験から、学習者間でのコミュニケ ーションのみでなく、学習者と教授者（教官なら びに TA）とのコミュニケーションも重要であるこ とがわかっている。我々はソフトウェア開発の上 流工程での学習者と教授者とのコミュニケーショ ンをインスペクションという活動を中心に行って いる。著者らはこれまでにソフトウェア設計・開 発教育におけるインスペクション支援システムを 提案してきた[5]。 本論文ではこれまでに開発して きたシステムを実際の授業に適用して得られた結 果、特に、インスペクションで指摘されたコメン トの分析結果を示し、システムの改善項目を識別 することを目的とする。 ２ 関連研究 インスペクションとは、ソフトウェア開発にお ける中間成果物である要求仕様書、設計書、ソー スプログラム等に含まれる間違いや矛盾を、イン スペクターと呼ばれるその成果物の著者以外が検. 出し、それをその著者や著者グループに対して指 摘を行うものである [2]。一般的には、準備、コ メントを収集するための会議、欠陥の修正という プロセスからなる[8]。これにより成果物の品質向 上をはかる活動である。したがって、インスペク ションは一種の協調作業と考えることができる。 近年、インスペクションプロセスに関する実験 に基づく研究が数多く行なわれ、さまざまな知見 が得られている[8]。また、インスペクションプロ セスを支援するシステムの研究開発も活発に行な われている。MacdonaldとMillerは、これまでに発 表されたインスペクション支援システムのサーベ イを行っている[6]。彼らはシステムが有する主要 な機能を以下の４つに体系化し、比較評価を行っ ている。 ・ 文書管理 ・ 個々のインスペクターの準備支援 ・ 会議支援 ・ データ収集 文書管理では、インスペクション活動で対象と する文書がテキスト文書か非テキスト文書か、コ メント付与の仕掛け、コメントの分類支援を比較 項目としている。個々のインスペクターの準備支 援では、欠陥検出の支援（例えば、チェックリス トの提示） の有無を比較している。 会議支援では、 対面の会議を開催するための日程調整に時間がか かる、また、会議参加のための出張費用の観点か ら分散同期型の会議システムを用いた会議支援を 実現するもの、会議が必ずしも欠陥検出率の向上 には寄与していないという実験結果[8]から、会議 を行わない、すなわち準備段階での結果をシステ ムにより自動的に蓄積、収集する非同期型の支援 環境に分類している。データ収集は、インスペク ションプロセス改善のためのデータ収集機構を提 供するもので、インスペクションに要した時間、 欠陥数、欠陥の種類や致命度等の指標を収集でき るようにしている。. ３ インスペクション支援システム ３．１ 教育用支援システムに対する要件の考察 これまで数多く開発されてきたシステムは必ず しも教育環境における学習支援を念頭に置いてい るわけではないことが伺える。教育環境における 支援システムでは、学習者グループに対する支援 のみでなく、学習者グループの状況を把握し、必 要であれば彼らをサポートする学習者と教授者間 の支援も必要である。インスペクションに関して 言うと、我々の経験では、対面による1グループに. −54−.
(3) 対する1回のインスペクションは約1時間を要し ている。そして、同一グループに対して何度かイ ンスペクションを行う必要がある場合もある。そ のため、授業の枠数の制約からすべてを授業時間 内に行うことは不可能である。また、授業時間以 外に、教官、TA、学習者グループのメンバーが一 同に会する時間を設定することも容易ではない。 そのため、関係者が地理的に分散し、非同期にイ ンスペクションを行うことができる環境が求めら れる。 複数のグループが並行して学習を進め、かつ、 何度かの修正を経て文書を完成させていく教育の 場では、以下の２つが重要であることがわかった が、これまで開発されてきたシステムでは、この ことについて言及していない。 * 教授者側が並行して行われている複数グループ の（場合によっては複数の成果物に対する）イン スペクションの状況を把握できなければならない。 * 成果物とそれに対するコメントの対応付け (あ る成果物のある版に対するコメントは、次回のイ ンスペクション会議に引き継がれる必要がある) 以上のような要件を満たすシステムを開発し た。その概要を次節で述べる。. インスペクションを受けるグループは、その対 象成果物をシステムに登録する。分析、設計工程 の仕様書は図やシステムの画面イメージなどを用 いて表現される場合が多い。現バージョンでは、 これらを扱えるワードプロセッサやプレゼンテー ションツールで作成した文書をシステム内にアッ プロードできるようにしている。インスペクショ ン依頼画面で対象物を指定すると、教授者側に依 頼があったことを示す通知が送られる。教授者側 は、インスペクション対象グループの対象成果物 のインスペクションを行うことを指定すると、コ メントを記述するウィンドウが開かれる。各イン スペクターはそれぞれ独立にコメントを記述し、 記述後、再度インスペクションが必要か否かを示 すボタンを押す。インスペクターは他のインスペ クターのコメントを参照することができる。すべ てのインスペクターのコメントが揃うと、教官が 「再インスペクション」 、 「指摘修正」 、 「完了」の アクションを起こす。再インスペクションは、今 回の指摘事項に基づき当該の成果物を修正し、再 度インスペクションが必要と判断したときに起さ れるアクションである。指摘修正とは、修正事項 が軽微であり、開発グループが指摘されたことを 修正するのみでよく、教授者側による再インスペ ３．２ 支援システムの概要 クションは不要という判断したときに起されるア 著者らの授業では、分析並びに概要設計で作成 クションである。完了とは、成果物が現状のまま される成果物に対してインスペクションを行って で承認されたときに起されるアクションである。 いる。前述の要件から、インターネットを介して 教官がこれら３つのうちのいずれかのアクショ 非同期にインスペクションが行える機能を提供し ンを取ると、対象グループに結果を示す通知が自 た。インスペクション支援は以下のような機能を 動的に送られる。再度インスペクションが不要と 提供している。 回答したインスペクターは、再度インスペクショ （１）インスペクションプロセスの支援 ンが行われる際、 アクションをとる必要はないが、 インスペクションは図１に示す手順で行われる。 コメントを加えることもできる。 （２）状況把握支援 教授者は全グループに対してインスペクション を行う。そして、１つのグループは複数の成果物 をインスペクション対象とし、さらに１つの成果 物に対して複数回のインスペクションを必要とす る場合がある。このため、教授者は状況把握に困 難をきたす。そこで状況を表示する機能を提供し た。成果物単位で、その成果物を担当するインス ペクターごとに、インスペクション実施の有無、 インスペクションが終わったものについては、修 正が必要か否かを表示している。これにより、イ ンスペクターは自身の作業状況を確認でき、 また、 教官は、インスペクションが遅れているインスペ クターを把握することもできる。 図１ インスペクションプロセス. −55−.
(4) （３）版管理、構成管理支援 ソフトウェア開発で作成される文書やプログラ ムは開発の進展にともないその中身の改訂が必要 となることがしばしば起こる。そこで、版管理が 必要となってくる。インスペクション時にも、イ ンスペクションでの結果を反映することにより成 果物は複数の版をもつことになり版管理が重要に なってくる。また、インスペクションの結果、新 たな文書の作成が必要になってくることもある。 このことはプログラムのみでなく、文書に対して も、構成管理が重要となることを意味する。 インスペクションの結果に基づき、文書を更新 し、再度インスペクションを行うことがある。そ の時文書の版管理とあわせて、インスペクション でのコメントも引き継がれるようにしている。こ れにより、インスペクターは前回指摘事項を確認 しながら新たに提出された文書の確認を行える。. タ構造について記述する文書である。 各グループのインスペクションにおけるインス ペクターは、 教官に加えて、 修士課程の学生 1 名、 １，２名の学部 4 年生から構成される。いずれも 本演習の履修経験者である。演習のカレンダー上 での期間は約 3 ヶ月（10 月中旬から１月中旬）で ある。したがって、インスペクションの期間をな るべく短くする必要がある。しかし一方で、ソフ トウェア開発における文書の重要性を認識させる べく、インスペクションはすべての文書が教授者 側に承認されるまで繰り返し行うようにしている。 表２は各年度における各成果物に対する、クラス 全体のインスペクション回数と、グループあたり の平均インスペクション回数（カッコ内の数字） を示している。この表から、各成果物とも平均し て２回はインスペクションが行われていることを 示している。. ４ 評価 本章ではシステムの適用結果について述べる。 システムを適用した2000年度と2001年度の受 講者数とグループ数を表１に示す。. 表２ 成果物ごとのインスペクション回数 2000 年度 2001 年度 仕様定義書 15(2.1) 13(2.6) ユースケース 16(2.3) 11(2.2) ｵﾌﾞｼﾞｪｸﾄﾓﾃﾞﾙ 19(2.4) 13(2.6) イベントトレース図 14(2.0) 10(2.0) 状態遷移図 17(2.3) 13(2.6) データフロー図 14(2.0) 10(2.0) UI 設計書 14(2.0) 15(3.0) DB 設計書 12(1.7) 11(2.2) 2000 年度と 2001 年度の全インスペクションに おけるコメントについて調査を行った。2000 年度 クラスのコメント数は 355 件で、2001 年度クラ スのコメント数は 221 件で、総合計は 576 件であ った。. −56−. 200 コメントの数. 150 100 50 13. 11. 9. 7. 5. 3. 0 1. 表１ 本システムを適用した 2 年間の受講者数 とグループ数 年度 受講者数 グループ数 2000 27 8 2001 15 5 本科目は東京学芸大学教育学部教育情報科学専 攻３年生の通年の選択科目である。前期はソフト ウェア工学の講義が中心で、グループによる開発 演習は後期に行われる。本演習では、ソフトウェ ア開発における分析段階ならびに概要設計段階で 作成する 8 種類の文書（仕様定義書、ユースケー ス図、 オブジェクトモデル、 イベントトレース図、 状態遷移図、データフロー図（DFD：Data Flow Diagram） 、UI 設計書、DB 設計書）をインスペ クション対象成果物としている。仕様定義書は、 教授者側から提示された問題文に対する自グルー プによる解釈を加筆し、追加機能(各グループとも 独自機能を１つ実現することが求められている) について定義する文書である。オブジェクトモデ ル、イベントトレース図、状態遷移図、データフ ロー図はオブジェクト指向開発方法論 OMT[9]で 規定されているシステム分析段階で作成するモデ ル図である。UI 設計書はシステムのユーザインタ フェース及び機能について記述するために作成す る。DB 設計書は、システムが永続的に扱うデー. コメントの種別. 2001年度のデータ 2000年度のデータ 図２ 種別ごとの指摘コメント数 各コメントを表３に示す 13 項目に手作業で分.
(5) 類した(分類を定義でき、各コメントを定義した分 類を対応付ける機能を現在実装中である)。 表３ インスペクションコメントの分類 分類項目. 説明. (1)不足. 記述の不足. (2)過剰. 記述の過多. (3)抽象的. 抽象的過ぎる記述. (4)わかりにくい. 記述内容がわかりにくい. (5)未定義. 未定義な用語. (6)整合性. 成果物間での整合性がとれていない. (7)間違い. 記述内容あるいはモデル表記の誤り. (8)根拠. 設計根拠不明. (9)項目未対応. 記述すべき事項が記述されていない. (10)指摘未対応. 過去のインスペクション時のコメン トへの未対応. (11)書き方. 表現が不適切. (12)改善提案. 仕様に対する改善提案. (13)形式. 文書形式上の不備. 図 ４に各コメントの分類結果を示す。 この図か ら、13 項目のうち、 「記述の不足」 、 「成果物間で の整合性がとれていない」 、 「記述内容あるいはモ デル表記の誤り」 、 「文書形式上の不備」という 4 項目に対する指摘事項が多いことがわかった。. 年度. 2001年度. 2000年度. 0%. 不足 未定義 項目未対応 形式. 20%. 過剰 整合性 指摘未対応. 40% 60% 割合 [%] 抽象的 間違い 書き方. 80%. 100%. わかりにくい 根拠 改善提案. 図４ コメントの種別ごとの割合 「記述の不足」と「記述内容あるいはモデル表 記の誤り」は本来インスペクションにおいて検出 されるべきものと考えられ、このことはインスペ クションが有効に機能していることを示している といえる。 「成果物間での整合性がとれていない」につい ては、次のような指摘コメントがあった。. ① オブジェクトモデルに記述されたクラス間で のメッセージの受け渡しはイベントトレース 図で表現されるにもかかわらず、オブジェク トモデルとイベントトレース図でクラス名が 異なっている ② オブジェクトモデルで定義されているメソッ ドは、イベントトレース図においてオブジェ クト間のメッセージの受け渡しとして表現さ れるはずであるが、表現されていない ③ 仕様定義書に、ある概念が追加されているに もかかわらず、それが関係する他の成果物に 反映されていない 分析、設計工程での作業形態として、全員で話 し合いにより検討を行い、文書化に際しては分担 執筆を行うという形態が多く見られた。①はデー タ辞書の作成と共有化といったシステム支援が必 要であることを示唆している。②はモデルの構成 要素の意味的な関連を、複数のモデル間で整合が とれているか否かを確認する機構が必要であるこ とを示している。③は変更管理の仕掛けが必要で あることを示している。 文書の形式に関しては、タイトル、作成者名、 日付、版数、改版履歴などが欠落していた。教授 者側からすると、 とりわけ改版履歴は必要である。 なぜならば、教授者はいくつかのグループが作成 する複数の文書を確認しなければならず、そのた め、修正点が明記されることにより、作業効率を 向上させることができるためである。ところが、 学習者はこのようなビジネス文書をはじめて作成 する者がほとんどであり、なぜ記述すべきかがわ からないということが明らかになった。これにつ いてはツール化により、項目の記入のチェックを 自動的に行うことができる。 図５と図６は、それぞれ 2000 年度及び 2001 年度における各成果物に対する、１インスペクシ ョンあたりのコメントの分類種別による割合を示 している。 この図から、UI 設計書と仕様定義書は記述項目 が不足している割合が平均よりも高く、また、仕 様定義書は未定義の用語が使われている割合が平 均よりも高い。イベントトレース図と DB 設計書 は、 整合性に関する指摘が多いという特徴がある。 これは、イベントトレース図や DB 設計書はオブ ジェクトモデルと関係が強いにもかかわらず、そ のことが十分理解されていないということを表し ているものと考えられる。. −57−.
(6) 究費補助金（奨励研究（A）課題番号 12780120） の支援を受けて行った。 ここに記して謝意を表す。 システムの実装を行ってくれた本研究室修士課 程修了生の長田圭史氏(現在、野村総合研究所勤 務)と学部卒業生の中野秋子氏(現在、PFU 勤務)に 感謝の意を表す。. 合計. 文書の種類. ＵＩ ＤＢ ＤＦＤ ＳＴＤ イベント オブジェクト シナリオ 仕様書 0%. 20%. 40% 60% 割合 [%]. 80%. 100%. 不足. 過剰. 抽象的. わかりにくい. 未定義. 整合性. 間違い. 根拠. 項目未対応. 指摘未対応. 書き方. 改善提案. 形式. 図５ 文書種別ごとのインスペクションコメン トの割合（2000 年度）. 合計 ＵＩ. 文書の種類. ＤＢ ＤＦＤ ＳＴＤ イベント オブジェクト シナリオ 仕様書 0%. 20%. 不足 未定義 項目未対応 形式. 40% 60% 割合 [%] 過剰 整合性 指摘未対応. 抽象的 間違い 書き方. 80%. 100%. わかりにくい 根拠 改善提案. 図６ 文書種別ごとのインスペクションコメン トの割合（2001 年度）. ５ おわりに 本論文では、大学におけるソフトウェア設計・ 開発演習教育におけるインスペクション支援シス テムの適用により蓄積されたコメントの分析結果 について述べた。この結果から支援システムに対 する改善項目として、 成果物間の整合性検証支援、 インスペクションコメントの分類支援、文書の形 式チェック支援が必要であることが明らかになっ た。今後はこれらの改善項目の開発を進める予定 である。. 参考文献 [1] J. Brown, Bloodshot Eyes: Workload Issue in Computer Science Project Courses, Proceedings of the 7th Asia Pacific Software Engineering Conference (APSEC2000), IEEE Computer Society Press, pp. 46-52, Singapore, December 2000. [2] T. Gilb, D. Graham, Software Inspection, 1993. [3] 櫨山淳雄，長田圭史，宮寺庸造, 横山節雄， 業務ソフトウェア設計・開発教育支援システム， 教育システム情報学会誌, Vol. 17, No. 3 (秋号)， pp．251-262, 2000. [4] 櫨山淳雄，業務ソフトウェア設計・開発教育 の実践とその評価, 教育システム情報学会誌, Vol. 17, No. 3 (秋号), pp. 367-378, 2000． [5] 櫨山淳雄, 中野秋子，ソフトウェア設計・開発 グループ演習教育のためのコミュニケーション支 援システム, 情報処理学会論文誌，Vol.42, No.11, pp. 2550-2561, 2001 年 11 月. [6] F. Macdonald, and J. Miller, A Comparison of Computer Support Systems for Software Inspection, Automated Software Engineering 6, pp. 291 – 313, 1999. [7] 松本吉弘, IT 時代に対応する大学のソフトウ ェアエンジニアリング教育，情報処理，Vol.42， No．1，pp. 99-100，2001 年 1 月. [8] D. E. Perry, A. Porter, M. W. Wade, L. G. Votta, and J. Perpich, Reducing Inspection Interval in Large-Scale Software Development, IEEE Transactions on Software Engineering, Vol. 28, No. 7, pp. 695-705, July 2002. [9] J. Rumbaugh, et al., Object Oriented Modeling and Design, Prentice-Hall, 1991. [10] S. Shoenig, Supporting a Software Engineering Course with Lotus Note, Proceedings of the International Conference on Software Engineering Education and Practice (SEE&P1998), IEEE Computer Society Press, 1998.. 謝辞 本研究の一部は、 平成 12 年度文部科学省科学研. −58−.
(7)
関連したドキュメント
This paper introduces an on-line cooperative planning and design system and studies its educational application as an exercise tool for practicing public
Keywords: homology representation, permutation module, Andre permutations, simsun permutation, tangent and Genocchi
Research in mathematics education should address the relationship between language and mathematics learning from a theoretical perspective that combines current perspectives
pole placement, condition number, perturbation theory, Jordan form, explicit formulas, Cauchy matrix, Vandermonde matrix, stabilization, feedback gain, distance to
In order to be able to apply the Cartan–K¨ ahler theorem to prove existence of solutions in the real-analytic category, one needs a stronger result than Proposition 2.3; one needs
This paper presents an investigation into the mechanics of this specific problem and develops an analytical approach that accounts for the effects of geometrical and material data on
はじめに 中小造船所では、少子高齢化や熟練技術者・技能者の退職の影響等により、人材不足が
はじめに
