ソフトウェア工学Ⅱ

成果物は、下記のリンクに掲示されています。

デスマーチ

　基本設計から詳細設計、詳細設計からコーディングかけて、ウォーターフォール・モデルでプロジェクトを進めれていないと思います。今回の樹上整列では詳細設計がしっかりしていない（1人が詳細設計を考えた）ということもあって、デスマーチを歩みました。メンバーはそんなにデスマーチでなかったといいますが、私は間違いなく、デスマーチになったと思います。また、荻原先生のプロジェクト演習の方では詳細設計をしっかり固めたおかげでコーディングがかなりスムーズということがあったので、なおさら詳細設計をしっかりすべきだったと後悔しています。ただ、最初（コーディングの途中から滝登りするまで）はウォーターフォール・モデルで奇麗に進めていたので、各工程でメンバーが集まれないことがあったり、各クラスの本来の役割を見失った（これは良くありました）ときに、前の行程を振り返ることで方針を最初は統一することが出来ました。特に僕なんかは色々なことがあって、参加しづらい時期もあったので、どの程度プロジェクトが進んだのかをURL一本で確認できたというのは良かったです。

「教育」の「教」教えてもらう。

　プロジェクトを進めるにあたって、色々な方々（青木さん、玉田さん、大本さん、寺子屋ブラザーズ（特に森さん））に聞きに行ったのは本当に良かったです。設計が出来ただけでなく、設計に関する技法を玉田さんに教えていただいて、樹上整列はもちろん、paneの小テストでも生かすことができました。そして青木さんに直接、基本設計の報告にいったときに、基本設計を直すことができたおかげで、あとあとの悪循環を防げたので良かったです。特にブランチに関しては、当初ないクラスだったので、取り入れたことによって、階層の異なるブランチを結ぶことを可能にしました。また、なぞのクラスキャストエラーに関しては、寺子屋でずっと悩んでいたら、まさかの大本さんが見てくださって、一発解決してかつ、原因を知ることが出来ました。それから、森さんにはかなりお世話になったので、やはり能力のある人たちに聞きに行くのは、大事だと思いました。

「教育」の「育」育つ。

　今回のプロジェクトで成長できたと思います。何よりも、MVC, Pane, Utility, Scope, Project/Project_MVC_Exampleは、大分参考にして、作りました。そして、特にForestModel, ForestView, ForestControllerのスーパークラスであるMVCのクラスはフル活用しました。そのおかげで、ダブルバッファ、マウスリスナーの追加、MVCの構築などを大分楽に実現でき、良い教訓を得ました。さらに、コードリーディングを何度も繰り返して行くうちに、どのようにコーディングすれば良いかが、少しずつわかってきたので、「育つ」ことが出来たと思います。

M&A.

　今回チーム合併しましたが、「良かった」が7割、「そうでもない」が3割だと私は思います。時期的にもう少し早く合併していれば、良い感じにはなっていたかもしれませんが、最後の方だったのと実質加わったメンバーは1人で、結局コードも後から改変したのもあったので、微妙です。ただ、おかしな挙動が起こったときや、コードがおかしい場合に話し合えるメンバーが増えたことは良かったと思います。

どうすれば良くなったか。

　詳細設計をもっと固めるべきだった。それが、大きいと思います。詳細設計のときにメンバー全員で話し合い、それだけでコーディングが出来るようにするべきで、コーディングに力を入れるというスタイルで複数プログラミングすると、そのメンバーの能力（コードリーディングしていない）だったり、書き方の違いのせいで、何度も書き直してしまうという超効率の悪いプログラミングになってしまい、結果としてコーディングが遅くなってしまったので、もっと詳細設計をしっかり固めてからか、固めながらコーディングをし、メンバー全員にコードリーディングをしっかりさせないといけないと思いました。