2017 ソフトウェア設計及び演習用の班Wiki

• 一回目
  • 方向性決め
• 二回目
  • ものの操作と洗い出し
  • ゲームの詳しい内容についての話し合い
• 三回目
  • ものの操作と洗い出し
  • ゲームの詳しい要素についての話し合い
  • リポジトリ,subversionの設定
• 四回目
  • Glibについて
  • 企画書の作成
  • 内容について再度話し合い
  • ものの操作と洗い出しのまとめ
• 五回目
  • ものの洗い出しと操作
  • モジュール
  • ゲームの流れのまとめ
  • 各種パラメータについて
  • 担当の分担(ステータス画面)
• 六回目
  • モジュールについて
  • 分担分け
• 七回目
  • Emacsの使い方
  • プロトタイププログラミング
  • ヘッダファイル作成
• 八回目
  • wikiの中間発表ページ作成
  • プロトタイププログラミング
  • サブバージョンの使用
  • ライブラリを作る
• 九回目
  • 中間発表
• 十回目
  • モジュール化
  • 分担
  • 内部設計部品作り
• 十一回目
  • 臨時休校
  • 分担モジュールの内部設計
• 十二回目
  • 分担モジュールの実装、モジュールの単体テスト
• 十三回目
  • 分担モジュールの内部設計 単体テスト 統合テスト
• 十四回目
  • 統合テスト 発表準備
• 十五回目
  • 発表

• データ
• 統合

• 今回の開発ではデータ担当ということで基本的な変数とその操作ができる関数をいくつか作ったが、後になって見返してみるとほとんど使わなかった関数もたくさんあった。また、建物などの変数も作ってみると、予想外なことに特定のモジュールでしか使わないものが多かった。
  これらのことを踏まえると、最初の話し合いで変数等の名前だけ統一して決めて、それぞれの担当に任せてしまい、わざわざデータ担当として割り振る必要もなかったのではないかと考えている。その方がその分の労力を別の要素にかけることができ、より良いものが作れたはずだ。
  また、前述の担当のため序盤はGTKに触ることもほとんどなく、そういった点でも反省している。
  
• 終盤は統合を行った。前半部ではGTKにほとんど触れることもなかったが、統合ではそうもいかず、これを担当したことでGTKへの理解は深まった。統合の際に困ったことは、コンパイル・データのやり取り・それぞれの関数の働きの把握だろうか。
  コンパイルでは、ヘッダファイルを使っていいないモジュールも多く、コンパイルの際に<stdio.h>をインクルードしただけのヘッダファイルを新しくやっつけで作るといったようなこともし、かなり無駄のことをしてしまったと反省している。もう少し時間があれば、それぞれのヘッダファイルもきちんとかけたのだが、関数の動きの把握に時間がかかってしまった。
  ファイルが増えてしまい見にくくなったのも失敗だった。それぞれ、モジュールごとにフォルダを作るようにするべきだったように思う。
  データのやり取りでは、構造体のデータ渡しなどに始まる、返り値・引数がうまく統一が取れていなかったように思う。これは最初の話し合いの時にインターフェースをしっかり決めていなかったことによるものだろう。
  関数の働きの把握については、前述のヘッダファイルがないという事も原因である。統合の際にモジュールを見たところ、似たような動作を繰り返し記述しているところも多くみられ、もっとそれぞれのモジュールで関数化を進めわかりやすいプログラムにするべきだった。 統合の際に、うまく関数化できればよかったのだが単純に統合するだけでもかなり時間をとられ、時間がなかなか足りず難しい面もあった。
  時間の見通しが甘かったという事だろう。
  
• 今回はGUIでの開発ができ、また複数人でやったという事もあり、貴重で重要な体験をつめた。

reademe.html
module.html