@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
機能設計は,何を行うことを指すのか.
1
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-06-23 07:43
■知りたいこと:機能設計は,何を行うことを指すのか.
自身は,機能設計とは,「機能要件,非機能要件を 踏まえて,システムの機能を設計すること」 と認識しております. で,知りたいことは,機能設計は,以下のどこまでの範囲を指すのか という事です. 1.機能を洗い出すこと 2.機能の実装方法を決めること. 具体的には,機能をパッケージで実現するのか, それとも独自に作りこむのか決定すること. | ||||||||
|
投稿日時: 2006-06-28 00:51
設計に対する考えは、企業や人によって千差万別だから、それを前提にして聞いて欲しいんだけど。
初心者ならば2、慣れたら1で効率的に作業を進めればいいんじゃぁないかなぁ。 設計関連の本ではよく「設計段階で実装方法は考えてはいけない」とあるけど、実際のところは「実装方法まで考えたら思考範囲が狭くなる」または「設計効率が悪くなる」という戒めで捉えた方が無難だと思うよ。 例えば、設計経験の無い人は思考の手順として、手馴れた実装方法から逆算して今何をするのか考えて行動する以外に設計手順を持っていないでしょ。もしそれ以外の方法が存在するならば、実装手段を知らなくても設計できる事を意味し、それはきっと皆がノドから手が出るほどに知りたい事じゃぁないかなぁ。 結局、分析も要件定義も設計もシステムを用意(プログラム開発)する為の前準備だからね。
機能をパッケージで実現するのかそれとも独自に作りこむのか決定は、要件定義から実装工程までの全工程に存在すると思うよ。 | ||||||||
|
投稿日時: 2006-06-28 04:05
私もこう言った話はいつも迷いますね。
はにまるさんの言う通り、設計に対する考えは、企業や人によって千差万別だと思います。 当然プロジェクトによっても違うと思います。 私が経験したプロジェクトについて書いてみると ほとんどを国内で作ったプロジェクトでは、機能設計は機能分割と構造化やデータ設計に終始し、実装方式は次のフェーズで決める方式を取っていました。(1.機能を洗い出すこと) オフショア中心で作ったプロジェクトでは、コーディングはほとんどオフショア。ついでに詳細設計も一緒にオフショア。なんてプロジェクトでしたので、機能設計書は実装よりに書いていました。(2.機能の実装方法を決める) プロジェクトの方針や環境によって、機能設計をどこまでするかは変わると思いますが、私個人の基準としては、如何に変更を反映し易いようにするか、がポイントだと考えています。(最近は、最初に提示する見積もりは最小限にして受注し、後々仕様変更等でお金を取っていく場合が多いし。。。) 『1.機能を洗い出すこと』の方が機能設計時のドキュメント量が少なく、仕様変更などに対して上流工程での影響範囲の洗い出しや検証等が行い易いと思いますが、オフショアに対してそんな設計書を出してもちゃんとしたモノが出来上がりません。ですので、オフショアの場合は『2.機能の実装方法を決める』まで行った方が速いときがあります。ただ、2.の場合はドキュメント量が実装寄りになるにつれ増大し、仕様変更などに対して影響範囲の洗い出しや検証等が行い難くなります。ですので、その辺の工夫は必要となります。 正直な話、一番最初に作るときなんかは『1.機能を洗い出すこと』にしようが『2.機能の実装方法を決めること』にしようが、あまり変わらないと思います。違いは「変更」があった場合の反映のし易さ(効率の良さ)だと考えています。完璧なものを最初から作ることなんて不可能だし、変更を効率よく反映させれるように調整すればよいと思います。 | ||||||||
|
投稿日時: 2006-07-28 17:07
>私個人の基準としては、如何に変更を反映し易いようにするか、がポイントだと考えて
>います。 アドバイスありがとうございます. 仕様の変更に備えて,機能の拡張性を考慮して機能設計をすすめていくことが 大事なのですね!気をつけたいと思います. |
1