最近周りで開発手法やらのハナシを耳にすることが多いデス。
といってもXPとかRUPとかがどうのというハナシじゃなくて、実際のところ
どういう風にヒト割り振ったりどういう手順で進めてくのがいいか。とかそ
ういうハナシですケド。
そんで、まあプロジェクトチーム(あるいは会社)としての開発手法ウンヌ
ンがどうだって前に、オレ自身はどうやって実装に入ってるのかなあ。
ってのをちょっと考えてみました。現実には実装した後のハナシも重要な
んですが、まあ雑文ということで。
お客さんからシステム開発のシゴトを受注したり、仲間内でこういうの作
ろうってなったり(小さなOSSとか)、(ダレに頼まれたワケでもないのに)
勝手にプログラム作ったりというときにどんな流れでコードを書きはじめる
のかってーと、
それぞれどういう作業かというと、
1.は、そのままですかねー。お客さんからイロイロ聞きだしたり(このシゴト
がオレに割りあたることはあまりないですケド)、仲間と相談したり、自問
自答したりして集めます。
コレは、ハッキリしてるものや漠然としたものや細かいものやフンイキ的な
ものすべてですね。
2.は1.で集まったものから(概念的な)モデルを構築する作業デス。要求
ってのはこれから作るものを示す断片的な情報群なので、そっからどんな
モノを作ろうとしてるのかってのを探りマス。
コンセプトもココであきらかになるのかなあ。
ここで矛盾があったりすると、要求のうちあるものは却下したり相談が必
要だったりちょっと脇に置いといたりします。
3.は実装全体の枠組みがどんなものか決めるってことですねー。といって
も2.で得られるモデルによってはソレナリに絞られます。予算とか期間なん
かも影響しますね。使用するプロダクトなんかもココで検討するかなあ。
4.は、2.で得られるモデルに(ビジネスとか運用とかから)イロイロな縛りを
いれてくようなカンジですかねー。
実装時に守るべきルール群とかそんなのです。
5.は、2.で得られるモデルをベースに、3.とか4.とかに適合するようにコード
を書いてく作業デス。
observationっていうのですかねー。想像上のユーザを観察しながら実装
できる程度には2.のモデルは理解しときたいデス。
もちろんコレは一実装者の見解なので、立場が違えばまた違った感覚
だとは思いマス。設計フェーズが終わってる状態のプロジェクトに作業員
として突っ込まれる場合はイキナリ5.でしょうし。その場合でも2.の結果の
モデルは知っときたいトコですねー。
そういえば、上記の手順だと設計してませんね。設計書を書くなら5.の前
でしょうねー。基本設計/詳細設計共に。個人的には設計の意義という
のはパッと思いつかないですね。設計書を残したいから設計する。みた
いな、あまり建設的とは思えないイメージがありますかねえ。
でも、実装するときに実装するヒトが必要を感じて書くのは別かなあ。
そのへんは各自の自由というかやりやすい方法でいいと思うので。
ようするに設計(者)と実装(者)を分離する意義が理解できてない。って
コトですかね。
まあなんだかとりとめないカンジですけど、オレの中では要求分析で得
られるモデルが、実装(だけじゃなくて仕様/アーキテクチャ/設計)の
軸になってるっぽいフンイキですねー。
といってもXPとかRUPとかがどうのというハナシじゃなくて、実際のところ
どういう風にヒト割り振ったりどういう手順で進めてくのがいいか。とかそ
ういうハナシですケド。
そんで、まあプロジェクトチーム(あるいは会社)としての開発手法ウンヌ
ンがどうだって前に、オレ自身はどうやって実装に入ってるのかなあ。
ってのをちょっと考えてみました。現実には実装した後のハナシも重要な
んですが、まあ雑文ということで。
お客さんからシステム開発のシゴトを受注したり、仲間内でこういうの作
ろうってなったり(小さなOSSとか)、(ダレに頼まれたワケでもないのに)
勝手にプログラム作ったりというときにどんな流れでコードを書きはじめる
のかってーと、
- 要求を収集する。
- 要求を分析する。
- アーキテクチャを決定する。
- 仕様を策定する。
- 実装する。
それぞれどういう作業かというと、
1.は、そのままですかねー。お客さんからイロイロ聞きだしたり(このシゴト
がオレに割りあたることはあまりないですケド)、仲間と相談したり、自問
自答したりして集めます。
コレは、ハッキリしてるものや漠然としたものや細かいものやフンイキ的な
ものすべてですね。
2.は1.で集まったものから(概念的な)モデルを構築する作業デス。要求
ってのはこれから作るものを示す断片的な情報群なので、そっからどんな
モノを作ろうとしてるのかってのを探りマス。
コンセプトもココであきらかになるのかなあ。
ここで矛盾があったりすると、要求のうちあるものは却下したり相談が必
要だったりちょっと脇に置いといたりします。
3.は実装全体の枠組みがどんなものか決めるってことですねー。といって
も2.で得られるモデルによってはソレナリに絞られます。予算とか期間なん
かも影響しますね。使用するプロダクトなんかもココで検討するかなあ。
4.は、2.で得られるモデルに(ビジネスとか運用とかから)イロイロな縛りを
いれてくようなカンジですかねー。
実装時に守るべきルール群とかそんなのです。
5.は、2.で得られるモデルをベースに、3.とか4.とかに適合するようにコード
を書いてく作業デス。
observationっていうのですかねー。想像上のユーザを観察しながら実装
できる程度には2.のモデルは理解しときたいデス。
もちろんコレは一実装者の見解なので、立場が違えばまた違った感覚
だとは思いマス。設計フェーズが終わってる状態のプロジェクトに作業員
として突っ込まれる場合はイキナリ5.でしょうし。その場合でも2.の結果の
モデルは知っときたいトコですねー。
そういえば、上記の手順だと設計してませんね。設計書を書くなら5.の前
でしょうねー。基本設計/詳細設計共に。個人的には設計の意義という
のはパッと思いつかないですね。設計書を残したいから設計する。みた
いな、あまり建設的とは思えないイメージがありますかねえ。
でも、実装するときに実装するヒトが必要を感じて書くのは別かなあ。
そのへんは各自の自由というかやりやすい方法でいいと思うので。
ようするに設計(者)と実装(者)を分離する意義が理解できてない。って
コトですかね。
まあなんだかとりとめないカンジですけど、オレの中では要求分析で得
られるモデルが、実装(だけじゃなくて仕様/アーキテクチャ/設計)の
軸になってるっぽいフンイキですねー。