MSE 生は夏休みもインターンもなく、8月頭のプロダクトリリースに向けひたすら studio プロジェクトです。というわけで今期はこんな感じです。
[Estimating Software Development and Maintenance Projects]
MSE の5つのコアコース Models, Methods, Management, Analysis, Architecture をすべて履修したので、今期とっているクラスはこれひとつ。インストラクターは、去年 MSE の教授陣に加わった Eduardo Miranda 先生。なのでこのコースは MSE が始まって以来初めてのオファーになります。このコースで取り扱う内容は、
- Develop good & defensible estimates for software development and maintenance projects
- Translate effort estimates into feasible schedules
- Reason about cost, schedule and uncertainty using valid constructs
- Evaluate the reliability of different estimation techniques and models
- Analyze historical data, identify cost drivers and construct parametric models
見積もりは重要です。どう重要かというと、見積もり（コスト & スケジュール）を正しく行うことができなければ、新規契約の確保、タスクの分担、デッドラインの妥当性の評価、といったプロジェクトの立ち上げやプロジェクトの成功を左右するアクティビティに悪影響を与えるからです。
しかし、重要であると同時に見積もりは難しい。それは guessの精度の低さ と不確定要素が組み合わさるからだと私は思います。たとえば、私が過去に読んだ本 Software Estimation の中でこんなクイズがありました。
- Surface temperature of the Sun ?
- Latitude of Shanghai ?
- Area of the Asian continent ?
- The year of Alexander the Great's birth ? ・・・
ではソフトウェア開発では何を比較対照とすればよいのでしょう？うーん、CMMIレベル2で規定されているとおり、組織内プロジェクトの historical data でしょうか。しかし、過去に類似したプロジェクトが実際そうすんなり見つかるでしょうか？既存プロダクトの機能拡張やプロダクトライン開発であれば、どの historical data を使えばいいか"比較的"簡単に特定できるかもしれません。しかし、新しい開発環境（OS、プログラミング言語、その他開発ツール）、新しいチーム、そして新しいソフトウェアプロセス、と初物がトリプルでやってきたときには、どうすればいいのか？しかも、プロジェクトの途中で requirements が変わろうものなら、当初の見積もりは根底から覆されるわけです。Studio を8ヶ月間やってきたわけですが、見積もりに関してはまだ何のコツもつかめず、 "guesstimate" の域から出ることができません。
人、テクノロジー、プロセスというソフトウェア工学に登場する不確定要素は、計算機科学の分野で扱われる問題とは若干毛色が違うと私は思うのです。それは、人、テクノロジー、プロセスという3つの変数の振る舞いを予測することがあまりに困難だからです。まず人の振る舞いを考慮に入れるには、心理学の分野も絡んでくるかもしれません。Weinberg 氏の著作に"Psychology of Programming"というタイトルがあるのも興味深いです。人という要素が密接に絡んでくる時点で、複雑さのオーダーがすでにどれだけ跳ね上がっているのでしょう？テクノロジーに関しても、次のプロジェクトで新しいプログラミング言語と開発環境を使うよう指定された場合、チームの生産性にどの程度影響を及ぼすのか。そして、プロセスは？Agileか、Rational Unified Processか、Team Software Processか。チームがプロセスに従うことを拒否したら、プロジェクトのスケジュールにどのような影響を及ぼすのか。うーん、なんだか不確定要素に海におぼれているようです・・・
しかし、人、テクノロジー、プロセスという三大要素をコントロールするというチャレンジングな面に惹かれ、私はこのソフトウェア工学という分野を選びました（人の要素については、コントロールするというよりも、協調していくという表現の方が適切でしょうか）。そして、そのコントロール能力を高めるためには、現場で開発者として経験を積む以外に方法はないと考えています。これが、私が（もう当分は）academia ではなく industry の道に進もうと思った最大の理由です。
もちろん、この見積もりのクラスで全ての問題が解決できるエキスパートになれるわけではありません。ただ、見積もりの複雑さの本質は何なのかを見極める手がかりになればと思っています。
[Software Development Studio III]
春セメスターで築いたアーキテクチャをもとに、今期は実装に専念します。うちのチームは比較的新しい技術を使うよう、クライアントから要求されており、その制約が大きな壁となっています。この技術制約を実装の見積もりに含めないといけないので、今現在、皆でかなり苦戦しています。でも、過去に使ったことのない技術ばかりなので、逆にこのプロジェクトは楽しいです。クライアントの期待に応えられるよう、8月頭のリリースに向けて頑張ります！
そうそう、友人が今夏研究のインターンで NY の郊外に行くことが決まりました。新しい環境で彼はさらに自分を高めていくことでしょう。よっし、彼の頑張りに負けないよう、私もこのセメスターガチでいきます^^
追記：クイズの答え
1. 10,000°F/ 6,000°C
2. 31 degrees North
3. 44,390,000 square kilometers
4. 356 BC
0 件のコメント:
コメントを投稿