6.2 設計工程と成果物
設計工程では、まずユースケース図、画面遷移図の作成と画面モックアップを並行して作 成した。次に、ユースケース図の基に、クラスライブラリ部の各機能のユースケース記述を 作成した。画面モックアップに基づき、画面定義書を作成し、アプリケーション側表示を定 義した。最後、システムを楽譜表示、演奏情報表示・編集、演奏分析及び対応付け四つの部 分に分け、クラス図を作成した。
表 6-2 設計の成果物 成果物 実績 設計書 91ページ ユースケース図 4枚 ユースケース記述 24個 画面定義書 14ページ 画面遷移図 5枚
クラス図 1枚
工夫点
クラスライブラリを外部に公開することを目標としており、クラスライブラリ構造の 妥当性及びソースコードの可読性が最も重要なことである。実装する際に、ちゃんとオ ブジェクト指向を意識して、設計を行った。
6.3 実装工程と成果物
2010/01/17時点で、チーム全体として、ソースコード量を、以下に示す。協調演奏支援ア
プリケーションと演奏分析アプリケーションはNetBeansで開発したため、NetBeans自動 生成したソースコードがで含まれている。以下に、システム全体と筆者担当した演奏データ 表示・編集部分の空行を除いたコード量をに表す。
表 6-3 システム全体のコード量
成果物 実効行(行) コメント(行) 合計(行) クラスライブラリ(全体) 8663 4193 12856 協調演奏支援アプリケーション
(自動生成込み)
3326 613 3939
協調演奏支援アプリケーション (自動生成除く)
1334 455 1789
演奏分析アプリケーション (自動生成込み)
2561 687 3248
演奏分析アプリケーション (自動生成除く)
1361 512 1873
筆者担当した部分
演奏表示・編集クラスライブラリ 1493 474 1968 協調演奏支援アプリケーション
(演奏情報に関する部分)
500 100 600
工夫点
オブジェクト指向のコードの再利用性を最大限に引き出すことために、リファクタリング を行い、クローンコードを削減した。そして三分の一コードを減らすし、システムの反応時 間を短くし、可読性を高める。
反省点
6.1節の反省点に記述した通り、実装工程の期間は計画より二倍かかった。原因としては、
実装したシステムの規模が見積もった規模より大きかった、見積もり段階で各機能を考えら れなかった、開発能力が不足等があげられる。
6.4 テスト工程と成果物
テスト工程では、単体テスト、結合テスト、総合テストを行った。チーム全体テストテス ト量を表 6-4に表わす。
表 6-4 テスト工程の成果物
実効行 コメント 合計
クラスライブラリ部 6002ステップ 2905ステップ 8907ステップ アプリケーション部 1833ステップ 469ステップ 2302ステップ 合計 7835ステップ 3374ステップ 11209ステップ
反省点
十分なテストが行えなかった
今回のテスト工程では、実装工程が計画より時間をかかったので、十分のテスト期間を取 れなかった。そのため、機能を優先順位を付けて、最優先の部分からテストを行った、演奏 データ表示部分をホワイトボックステストせずに、ブラックボックステストで動作確認を行 ってしまった。今後のプロジェクトでは、十分なテスト期間を取って、各部分をテスト行わ なければいけないということを分かった。