
● システム開発 プロトタイピング
システム開発工程の早い段階で試作品(プロトタイプ)を作成し、利用者に評価してもらうことにより、利用者と開発者の間の認識のズレを早期に解消するための手法です。
プロトタイピングでは、後工程での仕様修正を抑えることができる。
ということなのですが、弊社個人が受けている案件ではまず使わないです。試作品の予算、工数が必要ですから。
開発手法からは外れるかもしれませんが。
通販システムなどを作ったとします。作った後に100%の満足はありません。多少、ここはこうしたほうが良かった、とか出ます。不具合とかではなくて特に後の修整、追加などについてです。
次の通販システムでは前の反省点がありますから、そこを特に重点的に考えてシステム開発します。
つまり、経験そのものがプロトタイプみたいなものです。
大規模で予算も大きく、会社の基幹に関わるものなら本当に試作品(プロトタイプ)は必要だと思います。
ただ、机で考えた通りにはいきません、システム開発された試作品でOKが出ても、完了まで平和に行くとは限りません。顧客が試作品を正しく評価できるか、曖昧にOKを出して、完了してからクレームがつく可能性大です。
私の開発手法は大きく見るとウォータフォールなのですが、システム開発前に1週間単位で分割して資料で画面を確認してもらっているのでプロトタイプを紙面的に見てもらっている形です。
ウォータフォールにプロトタイピングを組み込んだ形みたいですが、今までの経験の中にウォータフォール、プロトタイピングを意識している訳ではありません。常に顧客を見て考えたやり方です。
現場でこういう理屈のやり取りがされているのか、と疑問に思います。現場では無い、理屈で仕事をしているエライ人たちが言っているような気がします。
人間が、そう簡単に動く訳が無い。ですよね。
聞いた話ですが、ある会社がプロトタイピングを作って顧客からの意見を聞いて修整を何回もしたらしい。
これでOKというところで、そして本番でシステム開発が始まった。
しかし、しかし、・・・顧客はプロトタイピングで修整依頼に慣れたせいか、本番に入ってからも修整、追加、修整、追加・・・・。
何の意味もありません、ウォータフォールの出来損ないです。
プロトタイピングで顧客の完全な了解を取り付けるということが難しい問題として残るのです。
結局、交渉力が土台にないと、どんな手法も一緒でしょう。
こちらが作った、画面資料にある項目も確認しない人が多いし。
工程毎の確認はシビアにお願いします。ほんとに。
腕時計のご紹介
サルバトーレマーラ
シチズン
|
■PHP関数一覧
日付・時刻関数
date_timezone_get()
指定した DateTime に関連するタイムゾーンを返す
date_timezone_set()
DateTime オブジェクトのタイムゾーンを設定する
date()
ローカルの日付/時刻を書式化する
getdate()
日付/時刻情報を取得する
gettimeofday()
現在の時間を得る
gmdate()
GMT/UTC の日付/時刻を書式化する
gmmktime()
GMT 日付から Unix タイムスタンプを取得する
gmstrftime()
ロケールの設定に基づいて GMT/UTC 時刻/日付をフォーマットする
idate()
ローカルな時刻/日付を整数として整形する
localtime()
ローカルタイムを得る
microtime()
現在の Unix タイムスタンプをマイクロ秒まで返す
mktime()
日付を Unix のタイムスタンプとして取得する
strftime()
ロケールの設定に基づいてローカルな日付・時間をフォーマットする
|
|
|