SQLの窓 イラストAC フリー素材

2013年12月14日

仕様書の書き方?? スケジュール管理??

Google+ のコミュニティですが、答えるとなると長文が書ける・・・。

質問をする為の掲示板は昔からありましたが、Google+ はちょっと作業しづらい感があります。そのせいか、他の内容がだいたいにおいて漠然としていて、とても本腰入れて返答したようには見えないし、質問側も返答に対するレスポンスがぱっとしない・・・。プログラマ専用にもっと広いフィールドが欲しいですよね。

開発経験の無い人は、『スケジュール』という文言の意味するところが実感できていません。単なる『予定』と思っている人が多いです。開発は、納期が必ず決まっているのでそこからの逆算で、人員を用意しています。個々のスケジュール管理は全体から見た微調整で、遅れれば、なにらかのテコ入れが必要ですし、進めば
前倒しが必然となります。

また、そうした前提でスケジュールを立てるにしても、持ち時間を全てプログラミングに使えるわけでは無く、移動や休憩や会議もあります。それらをふまえて週間単位で予定を考えるところから『スキル』が必要である事になります。全く持って単純では無いわけなんですが・・・・

学生なんかのやってるのは、全く殆ど『ままごと』です。

1) プログラム一覧

  スケジュール管理に必要になります
  スケジュール管理するには、時間見積りが必要です
  時間見積りするには、見積りする単位が必要です
  一般的にはエンドユーザのタスク単位になります

2) 入力設計書

   画面設計書と入力項目単位のチェックや属性
  できればエラーメッセージの定義も欲しいです

3) 出力設計書

   広い意味では、画面に対する編集処理も含まれますが
  一般的には、テーブルに対する更新方法の定義です
  さらに、印刷帳票のフォーマット設計も含まれます

4) テーブル設計

  これは基本設計として、システムに必要な項目を
  プロが並べ替えたものですが、エンドユーザへの
  確認資料にもなります。

5) 概要書

  これ一枚でプログラム単位の一つの全体像が全て
  認識できるものです。このフォーマットが会社単位で
  違いますが、1) 〜 4) は目的に沿っておれば内容は皆同じです

6) オブジェクト定義

  今時の開発ではこれらも必要となるのでしょうが、これこそ
  会社によって全く違うものになると思います。
  正直ここは良く解りませんが、昔は機能定義とか関数定義
  等で、ブログラマ寄りの設計書であったため、作られる事
  がまれではありました。

7) スケジュール

  本来は、開発メンバの為に存在するのでは無く、会社が
  クライアントの納期を守る為にあります。ですから、
  プログラム単位のスゲジュールと、担当者単位の
  スケジュールで管理者が管理します。

8) ガントチャート

  スケジュールはこの方式で語られる事が多いようですが、
  予定と実績が管理できるものが、週間・月間で検証できる
  ものであれば良いです。

  とは言うものの、見積りが無い以上スケジュールは
  無意味ではあります。また、一日に使える時間を把握
  していないと、また無意味です。

  最初は、その見積りができるようになる為に、仮のスケ
  ジュールで開発し、それに使われた時間を記録しておいて
  プログラム単位でのボリュームを理解する必要があります


【システム開発の最新記事】
posted by at 2013-12-14 20:41 | システム開発 | このブログの読者になる | 更新情報をチェックする