(文責:川勝)
松澤氏の依頼により、今まで述べてきたような過程で作り上げてきたアプリケーションみるみるを 「みるみるができるまで」という名でドキュメンテーションすることになった。 大岩研究会でウェブアプリケーションを実装するにあたって助けとなるようなものを作ることが このドキュメンテーション化の目的であった。
以下構成のみについてだが述べておくので参考にして頂きたい。
大岩研究室に残すドキュメントを作るということだったので、私たちはしっかりした構成のものを作る必要があると考えた。 そこでまず、各自が持ち寄った構成案を見ながらドキュメントの骨組みとなる部分を挙げていき、 議論しながら小見出しを考えていくことにした。
ここで重視したのは構成である。作業の順序は実際と多少異なっていても、 一般にアプリケーションを実装するのとほぼ同じように、企画、設計、実装、評価の4段階で分けられた骨組みに沿って述べていく形式をとった。 以下がその構成案である。
みるみるドキュメント章立て案 --構成重視版 0．概略 大岩研の研究プロジェクト 1．企画と用件定義 背景(去年の岸君の研究プロジェクトを引き継ぐ) 企画 クライアント決定 機能決定 要求定義 シナリオ作成 画面遷移図作成 (ロールプレイングによる作成) UC図(シナリオ、画面遷移図から作成) 2．設計 分析モデル 話し合いで作ったクラス図 オブジェクト図から作ったクラス図 設計モデル アーキテクチャの作成(分担も一緒に書いてあるやつ) 状態遷移図の作成(Servlet、jsp) フォームのデータ仕様決定 →これは本当は共同開発のとこでやった 3．実装 共同開発のための準備 個別開発(CUI) ソースコードレビュー(コード規約作成) 共同開発(分担による開発) 開発環境の統一(JDK、eclipse、CVS) 基準作成(サーブレットサンプル作成) 話し合い(仕様変更などの問題解決(メッセ、メールなどによる)) 4．評価 デバッグ 部分(ServletのテストをするためにCUIでも動くようにした) 全体(バグ集作成) ユーザテスト 第1回→失敗(JavaScriptエラーなど)→参加者にバグを報告して貰う 第2回→ほぼ成功→細かいところのチェック
構成重視案の欠点は、私たちが作業した順序とは異なっていることだった。 私たちが作るべきドキュメントは「大岩研究室においてこのドキュメントがあればウェブアプリケーションを製作できる」 というものであった。 その点を考慮すると作業の順序どおりに書くことが非常に大きな意味を持つことに気づいた。 私たちは順序を最優先して考えるべきだったのである。 自分たちが作業してきたとおりの順序で作業すればアプリケーションが製作できるようにするということを示すことこそ 私たちに求められていたことだったのだ。
そこで松澤氏の助言を参考にしながら、再度ドキュメントの構成を考え直してみた。 以下がその構成案である。
みるみるドキュメント章立て案 --流れ重視版 0．はじめに -松澤さん 大岩研の研究プロジェクトである 半期で進めていった流れ(スケジュール) 研究会での進捗報告 1．企画 -岸 背景(去年の岸君の研究プロジェクトを引き継いだ) 企画書 盛りだくさんの企画書 企画書の完成 --part1 分析フェーズ -川勝 2．仕様の定義 要求把握 流れの把握 機能決定 用件定義 シナリオの作成 画面遷移図の作成 UC図の作成(シナリオ、画面遷移図から作成) 3．分析モデルの作成 分析モデルの作成 クラス図の作成(オブジェクト図によるクラス図作成) --part2 設計フェーズ -阿部 4．プロトタイピング 個別開発(CUI) ソースコードレビュー(コード規約作成、英語クラス名統一) 5．設計モデルの作成 アーキテクチャの作成(分担も一緒に書いてあるやつ) 状態遷移図の作成(Servlet、jsp) フォームのデータ仕様決定 --part3 実装フェーズ 6．開発環境の整備 -阿部 開発環境の統一(JDK、eclipse、CVS) 基準作成(サーブレットサンプル作成) 7．実装 話し合い(仕様変更などの問題解決(メッセ、メールなどによる)) デバッグ 部分(ServletのテストをするためにCUIでも動くようにした) 全体(バグ集作成) 岸部分 川勝部分 阿部部分 --part4 評価フェーズ -川勝 8．評価 ユーザテスト 第1回→失敗(JavaScriptエラーなど)→参加者にバグを報告して貰う 第2回→ほぼ成功→細かいところのチェック 9．ドキュメンテーション -川勝 構成重視版 流れ重視版 付録:コード規約 -岸 全体統括 -岸