« 2006年04月 | メイン | 2006年06月 »
2006年05月27日
GoogleMapAPI
ちなみにこんなページもあります。（Googleじゃありっません）
2006年05月26日
テスト
↓このページから引用しました↓
http://ameblo.jp/argv/entry-10008018829.html
建築屋は鉄を、システム屋はテストを削る
テーマ：テスト
昨年から話題の耐震偽装問題。簡単にいえば、建物に使う鉄筋の量を減らすことで、材料費を安くして儲けようというわけだ。
ソフトウェアの開発プロセスは、時折、建築のプロセスに例えられる。しかし、決定的な違いがある。ソフトウェアには物質的な「材料」がないのだ。だから、材料費を削ろうにも削れないので、安心 ・・・ なんてことは全くない。
ソフトウェアは、ほとんど「人力」で出来ている。削れるものがあるとすれば、人間の作業時間、つまり開発工数なのである。費用面でも、人月（にんげつ）ベースの価格設定をしているような受託開発では、開発工数（期間×人数）が少ないほうが、安くなる。
↓このページから引用しました↓
http://ameblo.jp/argv/entry-10008018829.html
★
もちろん、普通のシステム開発会社が、悪意のある「偽装」をすることはないだろう（と思いたい）。問題は、顧客から無理な納期を設定された場合である。金額面での要求なら、営業的な対応もできる。しかし、開発期間が十分に確保できないにもかかわらず、納期を延ばしてもらえず、要件も削ってもらえない、といった状況は、どうしようもない（※１）。
当然、開発者は、出来ないものは出来ないと主張するだろう。見積精度云々の問題もあろうが、その道のプロが出来ないと言うのだから、出来ないとみなすのが正しい判断だ。しかし、顧客は「なんとかしてくれ」という。そして、商売上の理由だとか会社の力関係だとか、技術者には理解できない暗黒の力が働いて、結局は開発がスタートしてしまうのである。
開発者が、無理な納期を守るために、まずできることは、残業や休日出勤による作業量の確保である。この業界では、徹夜続きでおかしくなってしまった人の話は珍しくない。鉄筋を削る前に自分の命を削るあたり、耐震偽装の連中とは違うのである。
もちろん、開発手法の工夫や技術的な工夫によって、効率化できることもあるだろう。しかし、それにも限界がある。
↓このページから引用しました↓
http://ameblo.jp/argv/entry-10008018829.html
★
もともと出来る見込みのないことが出来るはずはない。やってみたら出来ました、なんて都合のいい話は期待しないほうがよい（※２）。結局、「出来たように見せかける」ための偽装が始まる。
システム開発で削られる「鉄筋」は、「テスト工数」だろう（※３）。結果としてモノが出来る工程ではないため、削りやすいのだ。もちろん、品質を確保する上で、最も重要といってもよい工程のはずなのだが・・・。
ひどいときには、発注者の側から「テスト工数は減らしてもいいから、納期内に納めてくれ」といった要求が出されることすらある。建築業者に「鉄筋を減らしてもいいから、安くしろ」と言うのと全く同じではないか。
品質はどうあれモノが出来ればよい、という考え方が、耐震偽装問題と同じなのである。しかし、こうして納期内に納められたモノは、実は全く「出来ていない」のだ。
品質の悪いシステムを使うことは、システム化をしない場合よりも悪い結果になることも多い。それなら、最初から納期を延ばしておけばよかった、ということになるのである。
↓このページから引用しました↓
http://ameblo.jp/argv/entry-10008018829.html
★
もちろん、開発側の問題で、納期に間に合わなくなることもある。しかし、私の経験からいえば、顧客側の無理なスケジューリングや、無理な仕様変更、要件提示の遅れなどが原因となることのほうが多いように思う。
納品を「する側」と「される側」とでは、どうしても納期というものを受け止める重さが違う。そのことが、スケジュールに対する姿勢の違いに現れるのだろう。
納期が動かせないようなプロジェクトなら、どうしてもっと早く取り組まないのか、と言いたくなることがよくある。開始が１ヶ月早かったら、無事に開発できただろうに、というケースもよくあるのだ。
システム開発を発注しようという人には、「納期厳守」という言葉がどういう意味を持つか、よく考えてもらいたいものである。
↓このページから引用しました↓
http://ameblo.jp/argv/entry-10008018829.html
※１
単純に作業者の数を増やせばよいという問題ではない。１人で100日掛かる仕事が、100人いれば１日でできるか、といえば、そんなことはない。システム開発は「袋貼り」のような単純作業ではないのだから。そんな簡単なことも分からない人は多いのだが・・・（→ 関連記事: 続・プログラマは誰でも同じ？）
※２
この業界は見積の精度が低いので、十分ありうることではある（→ 関連記事: やってみなきゃわからないという現実）。しかし、それを期待すべきではない。
※３
「悪魔に心を売っても納期を守る！ 裏技術 （@IT）」を読めば、システム屋は共感し、そうでない人は驚愕するだろう。これが現実である。
↓このページから引用しました↓
http://ameblo.jp/argv/entry-10008018829.html
2006年05月22日
Blog Deco iam
ブログパーツをデコレーションする
BlogDeco
キャスビー casvee
ユニーク:代表 米森哲二
ブログでライブ放送！Casvee [キャスビー] オープン
http://www.casvee.com
2006年05月19日
ウォーターフォールモデル
ウォーターフォールモデルとは
システムの開発手順を示すモデルの一つ。システム開発モデルとしては古典的なものである。システム全体を一括して管理し、分析・設計・実装・テスト・運用をこの順に行っていく(実際はもう少し細かく分ける)。各工程が完了する際に、前の工程への逆戻りが起こらないよう、綿密なチェックを行なう。水が瀧を流れ落ちるように開発が進んでいくことから、このような名称になった。しかし、実際の開発作業では頻繁に逆戻りが発生するため、ウォーターフォールモデルから派生する形で、逆戻りを考慮に入れたモデルが考案されている。
スパイラルモデル
スパイラルモデルとは
システムの開発手順を示すモデルの一つで、システムの一部分について設計・実装を行い、仮組みのプログラムを元に顧客からのフィードバックやインターフェースの検討などを経て、さらに設計・実装を繰り返していく手法のこと。
仕様の修正や再設計を考慮したモデルなので、ウォーターフォールモデルと比べて顧客の要求と最終実装が乖離しないという特長をもつ。
ただし、プロトタイプの作成に時間を要する分開発効率が低くなるほか、どの段階でプロトタイプから最終実装に格上げするかの判断が難しいといわれる。
単体テスト
単体テストとは
システムのテスト手法の一つで、個々のモジュール(部品)のみを対象としたテスト。対象のモジュールが仕様書で要求された機能や性能を満たしているかどうかをテストする。
複数のモジュールを組み合わせて行なうテストは結合テスト、システム全体を対象に行なうテストはシステムテストという。
モジュール
モジュールとは
機能単位、交換可能な構成部分という意味の英単語。システムへの接合部(インターフェース)が規格化・標準化されていて、容易に追加や削除ができ、ひとまとまりの機能を持った部品のこと。
パソコンのマザーボードなどは主要な部品がモジュール化されており、後から最新の部品に交換して全体を買い換えなくても性能を向上させられるようになっている。最近のソフトウェアやプログラミング言語は、あらかじめモジュールを組み込めるようなインターフェースを用意しておき、ユーザが自由に追加機能を開発して公開したり、全体を入れ替えることなく機能を強化するのに利用しているものが多い。
ボトムアップテスト
ボトムアップテストとは
複数のモジュールを結合させたプログラムを、下位モジュールから順に結合しながら検証していくテスト方法。
複数のモジュールを使用したプログラムを開発する場合、バグの発生個所を特定しやすくするために、全てのモジュールを組み合わせて一気にテストするのではなく少しずつ組み合わせながら順次テストしていく方式が一般的である。
このときにボトムアップテスト方式では、「ドライバ」と呼ばれるダミーの上位モジュールを用意して下位モジュールから順にテストしていく。
下位モジュールに問題がなければドライバを本物の(単体テストの完了した)上位モジュールと入れ替えて再びテストが行われ、以下問題が発見されるか全てのモジュールが結合された状態でテストが完了するまで、同様の手順が繰り返される。
最下位モジュールからテストしていくため、並行作業に向いているという利点がある。
なお、これとは逆に、上位モジュールから順に結合しながらテストする方法を「トップダウンテスト」という。
トップダウンテスト
トップダウンテストとは
複数のモジュールを結合させたプログラムを、上位モジュールから順に結合しながら検証していくテスト方法。
複数のモジュールを使用したプログラムを開発する場合、バグの発生個所を特定しやすくするために、全てのモジュールを組み合わせて一気にテストするのではなく少しずつ組み合わせながら順次テストしていく方式が一般的である。
このときにトップダウンテスト方式では、「スタブ」と呼ばれるダミーの下位モジュールを用意して上位モジュールから順にテストしていく。
上位モジュールに問題がなければスタブを本物の(単体テストの完了した)下位モジュールと入れ替えて再びテストが行われ、以下問題が発見されるか全てのモジュールが結合された状態でテストが完了するまで、同様の手順が繰り返される。
最上位モジュールからテストしていくため、重要な中核部分のエラーを早期に発見しやすいという利点がある。
なお、これとは逆に、下位モジュールから順に結合しながらテストする方法を「ボトムアップテスト」という。
スタブ
スタブとは
あるプログラムが他のプログラムを呼び出す際に仲介となるプログラム。スタブの仲介を受けることで、プロセス間通信やクライアント・サーバ間でのオブジェクト呼び出しなどを、通常の手続き呼び出しと同様に扱うことができるようになる。
アプリケーションがOSの機能であるシステムコールなどを利用する場合、直接目的のシステムコールを呼び出すのではなく、スタブを呼び出してシステムコールの呼び出しはスタブに任せることが多い。
また、分散環境のプログラムがサーバ上のオブジェクトを呼び出す場合に仲介するプログラムも、同じくスタブと呼ばれる。こちらはC言語やC++、Javaなどの環境で利用でき、プログラム本体から独立してインターフェースが提供されることで、プログラム自体では通信を意識しなくともサーバ上のオブジェクトが呼び出せるようになっている。
ブラックボックステスト
ブラックボックステストとは
システムの内部構造とは無関係に、外部から見た機能を検証するプログラムのテスト方法。
入力と出力だけに着目し、様々な入力に対して仕様書通りの出力が得られるかどうかを確認する。その間、システム内部でどういった処理が行われているかは一切問題としない。
限界値分析や同値分割などの方式があり、仕様と実際のプログラムとの差を調べることができるが、限定された状態でのみ起こるバグなどを完全に取り除くのは難しいとされる。
なお、これとは逆に、プログラムの機能よりも内部構造に着目して行なうテスト方法を「ホワイトボックステスト」という。
ホワイトボックステスト
ホワイトボックステストとは
システム内部の構造を理解した上でそれら一つ一つが意図した通りに動作しているかを確認する、プログラムのテスト方法。
「命令網羅」「判定条件網羅」「条件網羅」「複数条件網羅」「経路組み合わせ網羅」などの方式があるが、基本的にはプログラム内の全ての命令、全てのルーチンが最低一回は実行され、検証されるようになっている。
つまり、プログラムの全ての部分が、プログラム記述者の意図通りに動作していることを確認するテストである。システムの機能よりも内部構造の整合性を重視したテストとも言える。
網羅的なテストであるため珍しい事態に対しても動作確認できるのが利点だが、あくまでプログラム記述者の意図との整合性を確認するだけなので、記述者自身に誤解があった場合は対処できないという欠点も持つ。
これに対して、プログラムの内部構造とは関係なく、外部から見て仕様書通りの機能を持っているか確認するテストを「ブラックボックステスト」という。
