2008/10/27
【誰にでもできる！システム開発】ソフトウェアのプロセスモデル（前編）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
『誰にでもできる！システム開発』 2008/10/27 号
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ご愛読、ありがとうございます。
このメールマガジンは、システム開発を始めたばかりの方、これから始める
方向けに、筆者が日頃から心がけていることをお話しています。
扱う内容については、テクニックと考え方を半分ずつで構成しています。
思っていた内容と違う、つまらない、読む気力が無くなったという方、
購読解除はこちらからできます。
http://www.mag2.com/m/0000263428.html
著者プロフィール
http://www.shiga-it-office.com/mailmagazine/writer.html
事務所概要
http://www.shiga-it-office.com/profile.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■第22回 ソフトウェアのプロセスモデル（前編）
────────────────────────────────────
システム開発には様々なリスクがあります。
度重なる仕様変更、技術不足、納期の変更などによって、品質や収益が確保
できなくなることがあります。
プロジェクトは一旦崩れだすと、なかなか元に戻すことができず、ずるずる
と泥沼にはまってしまいます。
その様子を、デスマーチ（死の行進）と呼ぶ人もいます。
そうならないようにするために、ゴールを明確にします。
その上で、ゴールまでの過程をタスクに分け、メンバーの割り当てやスケジ
ュールを考えていくことになります。
それは、戦国時代の戦（いくさ）前に行われる評定（ひょうじょう）に似て
いるかもしれません。
すぐれた武将がどれだけいても、戦略がなければ相手の策に嵌り、なかなか
勝つことはできません。
システム開発も同じで、優れたエンジニアがいたとしても、度重なる仕様変
更に振り回され、膠着状態になっているプロジェクトを見かけます。
それでも納期は変わらないことが多いので、最後は優秀なエンジニアが力づ
くで解決しなければならなくなります。
結果としてプロジェクトは無事に終わったとしても、メンバーの増員や残業
のため、利益が出ないどころか大赤字なんていうこともあります。
せっかく頑張っても、これでは報われないですよね。
●ソフトウェアのプロセスモデル
とは言っても、戦略を立てるなんて誰でもできる訳はありません。
技術者とは要求される能力が全く異なるからです。
そんな状況を考え、有能な学者さんが研究し、編み出したプロセスモデルが
あります。
ソフトウェアプロセスモデル、開発工程モデルなどと呼び方は様々ですが、
ほぼ同義語なので、ここでは「ソフトウェアプロセスモデル」とします。
今回、次回と２回に分けて紹介していきたいと思います。
●ウォータフォールモデル
最もよく使われている手法です。
文字通り、滝の水が上から下に落ちてくるように、後戻りせず、順番にタス
クを進行させていきます。
大きく分けて、要求定義→システム設計→プログラム設計→コーディング→
テストという流れになり、各フェーズごとに完了基準を設けます。
・要求定義 … 発注者の目的を明確にし、ソフトウェアの機能・対象範囲
を決定します。
・システム設計 … 要求された機能をどのように実現していくかを決定し
ます。他システムとのインタフェースなども検討します。
・プログラム設計 … それぞれの機能をどのようにプログラミングしてい
くかを決定します。技術が実現可能かも確認します。
・コーディング … 設計書に従って、プログラムを作成します。
・テスト … 要求が満たされているかをチェックします。
上記の説明からも分かるように、上流の工程で作成された成果物に従って、
次フェーズが行われるため、上流工程の完成度が重要になってきます。
各フェーズは後戻りすることはありませんので、要求定義での漏れがあると
下流工程で予想以上のコストが発生する可能性があります。
多くの失敗プロジェクトでは、要求定義で要求が固まらないまま、下流工程
に移行していることが原因となっています。
------------------------------------------------------------------------
■編集後記
最後までお読みいただき、ありがとうございました。
読者の方からお便りをいただいたので紹介します。
と、言いたいところですが、まぐまぐには読者かどうかをチェックする機能
がありまして、確認したところ、読者ではありませんでした。
このメルマガは、読者の方に向けて情報を配信しておりますので、基本的に
いただいたお便りは、内容によりますが、個別対応は行わず、このメルマガ
上にて回答させていただきます。
それほど暇な訳ではありませんので、ご理解いただければと思います。
さて、内容についてですが、
除算の33÷6を (1)余りを出す、(2)割り切る という上記の2通りの方法で
2進数にしたいのですが、解説を読んでもいまひとつ分からずに困っていま
す。 加えて、割り切る方法の結果から分かることについても知りたいので
すが、よろしければご教授をお願いします。
とのことです。
宿題のニオイを感じますね。
「割り切る方法の結果から分かること」については、ご自身で考えていただ
くとして、割り算の考え方をもう一度おさらいしてみます。
割り算の考え方は、33の中に6はいくつありますか？ということですので、
33から6をいくつ引けるかを考えれば良いと思います。
ただ、この例の場合は数が小さいからいいですが、30億÷30というような大
きな数字の場合、ひたすら引いていくのは効率が良くありません。
そこで、6の倍数でまとめて引いてみます。
6×5は30で、33から引けますので、5が答えになります。
余りは33−30で、3ですね。
割り切りたければ、そのまま小数点計算を続けていけばいいのですが、2進
数は割り切れなくなることがあることは、以前にもお話していますね。
計算の考え方は10進数も2進数もほとんど同じです。
考えずに答えを求めるのではなく、頭と鉛筆を使いましょう。
ご感想・ご意見・ご要望などありましたら、気軽にご連絡ください♪
では、また来週お会いしましょう！
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
『誰にでもできる！システム開発』 2008/10/27 号
本日のメールマガジンを読んだ感想をお聞かせください。
お寄せいただいた感想は、メールマガジン上で紹介させていただくことが
ありますので、ご了承ください。
配信中止はこちらから↓
http://www.mag2.com/m/0000263428.html
メールアドレスの変更はこちらから↓
http://www.mag2.com/m/0000263428.html
ご意見＆ご感想はこちらから↓
http://www.shiga-it-office.com/mailmagazine/ImpressionFrom.html
コンサルティングのご相談はこちらから↓
http://www.shiga-it-office.com/inquiry.html
発行元 志賀IT事務所
http://www.shiga-it-office.com/
関連メールマガジン 「誰にでもできる！インターネット活用術」
http://www.mag2.com/m/0000263426.html
関連ブログ
☆コンサル日和
http://d.hatena.ne.jp/kei_onpu/
☆爆裂！Ｃ＃野郎
http://csharp.yaminabe.info/
☆10年戦える開発技術
http://10year.yaminabe.info/
☆情報処理技術者試験午前対策
http://am.yaminabe.info/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
