１　ソフトウェア開発に置いて、デバック、テスト期間を

1.は分かりませんが、2.は基本的によほど小さなプログラムでも

ない限りバグなしのものを作成することは不可能と言われています

ので、あり得ないと思います。

そんなことをしたら何が起こるか分かりません。

そのようなプログラムを使用する勇気があるなら別ですが...。

http://kei-it.tea-nifty.com/sailing/2006/05/post_d16b.html

開発の半分はテスト

ブログなので論証になるかどうかはあいまいなのですが･･･。

１．は、システムなどの特性によってある程度左右されてしまいますが、開発→テスト→バグ発見→バグ改修→再テスト

となるので、半分とはいかないまでも、少なくとも全工程の30％～40％程度はテストに使われるのではないでしょうか。

http://www.geocities.jp/bouasan2004/sozai/right2-1.html

■某Ａさんのエロゲークリエイター体験記３４

http://blog.livedoor.jp/eikopino/archives/19833866.html

デバッグしないで納品なんて先生怒りますよ。

http://www.atmarkit.co.jp/farc/rensai/heaven03/heaven03c.html

開発現場の天国と地獄

２．のほうは、あまり論証となりそうなページではありません。

参考までに、といったところでしょうか。

お役に立てず、申し訳ありません。

http://www.amazon.co.jp/exec/obidos/ASIN/4822281116/tumaminomido...

プロジェクト管理の理想はこちらの著書になります。

http://jibun.atmarkit.co.jp/fengineer/rensai/bookreview03/book01...

実情は「プロジェクトが混乱する元凶は何かを考える」になります。

ソフト開発と言う物は、道路工事やビル建設で活躍する鳶のような業務内容で、頭脳を使っていますが立派な肉体労働です。

暗礁に乗り上げるプロジェクトの原因は色々あると思いますが、

ポピュラーなのは、ソフト開発の基礎知識もない営業が受注し、

無知な営業もしくは顧客が機能に関する要件定義や納期を

決めてしまうケース。

経営だけで見た開発期間の短縮のケース。

顧客の要件定義が定まらず、二転三転するケース。

１に関しては規模によりますが、一人で組んでいる場合には

プログラマーはある程度のテストは行っています。

そのままでは想定外の動作をさせた場合に破綻するので、

中規模で最低１０日間～３ヶ月は行います。

それ以上になればもっと長いテスト期間を設けると思います。

チームで作った場合も1ヶ月前後は必要になってきます。

２に関してはすでに出来上がっているソフトを販売する場合に

考えられると思います。

参考になれば幸です。

うーん、質問内容とは違うんですが…コメントに対して追記させていただきます。

http://cis.k.hosei.ac.jp/~akonoma/hbookgslide.pdf

すごく長いPDFファイル(320ページ超！：本一冊まるまるですね、いいのかなこんなの…)なんで参考までに。

ここの30ページ（ソフトウェアライフサイクル)に「受入れテスト」の話が出ています。

つまり質問者さんの問題はソフトウェア開発契約時にどのような取り決めを開発元と行ったかがポイントになってきます。もし契約条項に「受け入れテストで問題があった場合は納品を拒否、直して持ってこい」のようなものが入っていれば…。

http://www.e-somu.com/download/business/rtf/soft-kaihatsu.rtf

手遅れかも知れませんが、この契約書だと第15条、第16条のあたりにそのような記述が明記されています。

これがない場合はそもそもテストしたかどうかを明確にするところから争わないといけないので大変です。(テストしてなくても完成している、と言う開発元も馬鹿だと思いますが…テストもばっちりですしっかり動いてましたと言われたらほんとにどうしようにないのに…)。

http://magazine.fujitsu.com/vol57-1/paper01.pdf

　明確な出典を言われると、元勤務先の詳細は非公開の開発手法ということになります。

　具体的なシステム名称と開発規模にもよると考えられます。例えば、帳票１枚印刷できるようにするとして、生データを流して、書式をチェックするだけで殆ど事足りますから、テスト工程は１割にも満たない。

　システムのデータが複雑になればなるほど、データの組み合わせも増えてきますのでテスト工数は増えてきます。

　各社の開発手法にもよりますし、開発言語にもよります。私が開発していた頃流行ったプレゼン手法などは画面や帳票の書式を作る毎に顧客に承認を求めましたので、ＰＧ完了＝書式に関するテストは終了という手法がないわけではありません。また、お客様との要件定義にどれだけ手間を割けるかという条件にもよりますので、一般企業向けであれば、工数ベースで新規開発なら２割から５割の間。中規模以上向けにパッケージのカスタマイズであれば１割から４割程度になります。

　yozoのシスアドへの道 | テスト

ただし、期間が自動的に決められる工程が一つあります。それが運用テストで、まずデータ移行に関するテストこれは本番移行のほぼ１ヶ月前から繰り返し、本番移行を行って旧システムと月初で同じ状態にしてから１ヶ月間並行運用して頂いて、レスポンスなども含めて１ヶ月間同じデータを入力した上で月末の締め処理を最後として評価を行います。結合テストと一部並行して行いますが、ここは移行システムなら２ヶ月半、新規導入で１ヶ月半は絶対必要です。

誤差 - Wikipedia

　テストはお金を扱うシステムなら絶対必要です。私が直接担当したわけではありませんが、給与関係のシステムで打ち切り誤差により１０００名に２～３人程度の割合で手取額を１，０００円少なく計算してしまうというトラブルがありました。

　コンピュータは人間が想像しない動作をすることがあります。確かに少ないデータで省力したいのは事実ですが、こういうバグもあることから十分なテストが必要です。

＞１　ソフトウェア開発に置いて、デバック、テスト期間を

＞どのくらい設けるのが一般的でしょうか。

裁判官の無知ぶりはおいといて、いろんな要因が絡むので、それは一概には言えないと思われます。

なぜかと言うと、まずどういう仕様があり、どういう動作が保証されるべきなのか、経験ある人が担当するのかしないのかで作業工数は変動し、更に何人でその仕事を行なうのかによって作業期間は変動します。

仮に作業見積り上、テスト項目が１００あったとしますか。

で、そのテストをするためには１日１人で5個しかこなせないような代物だったとしましょう。

すると作業工数は単純に考えると100個÷5個＝20日かかりますよね？

その場合、5個しかこなせないのがその人のスキルによるものなのか、誰がやってもどうしようもないものかでも話は違ってきますし、またお金あって人を大量に投入すれば短期間で終るものなのかもしれませんし、同じプログラムでも経験ある人が組めばもっと短納期でできるかもしれません。また、経験浅い人が組めばプログラムは異常系を想定しておらずバグは多くなり、プログラムはスパゲティ化して直せばデグレ起こし、再評価も何度も行なう必要出るので作業期間はどんどん延びていくのはよくある話しです。

理想を言えばCMMのレベル５の手順を踏む事が望ましいですが、そんな会社は少ないのが現状でしょう。

ほとんどの会社が開発者の技量に依存し、更にユーザーからの希望で短納期を望まれれば最初の設計や評価をいかに削って納品を希望納期にあわせるのかが敢えていうなら一般的な話かと思います。

＞２　付随した質問になりますが、デバック、テストを行わない

＞ソフトウェア開発というものはありえるでしょうか。

常識的にデバッグ、テストを全く行なわない開発はありえないと思います。

で、話はご相談の件に少し戻りますが、どういう仕様があって、どういうバグが発生しているのか分かりませんが、基本的に双方合意のとれている仕様についてのバグは作り側の問題なので責任を持って直すべきかと思いますが、仕様の取り決めや契約上、どこまで動作保証するのかというものが明確になっていないグレー部分については、論点が分かれるところかと思います。

作り手を庇うわけではありませんが、中小企業の仕事でよく聞くトラブルでは、最初の打ち合わせの話とどんどん変わっていって仕様がいつの間にか膨大に膨らんでいき、最初に見積もっていた費用や工数を超えるような作業を依頼されているパターンです。それは営業と現場サイドの認識の違いにも影響される事もあるでしょう。

従いまして契約書もさることながら

・仕様打ち合わせ議事録などもかき集める

・相手が動作確認した評価結果が提出されてないようであればそれも提出してもらい、その通りの動作になっているか検証する。

・バグの症状、発生手順、再現性などを纏める

必要があるのではないかと思います。

以上、ご参考まで。

http://www.atmarkit.co.jp/news/200509/21/tmx.html

1.基本的に使用テストが2割で、想定外テストが5割ですね。

2.ご承知かと思いますが、システム設計においてはレビューを行い、レビュー時に確認した使用内容が的確にPGに反映しているか否か野確認が、全工程の2割程度となります。

3.次にデータ長が可変か固定によっても相違しますが、当該データに異常データが含まれていた場合のシステム処理として、タスクアベンド機能停止か障害発生機能停止かの何れでシステム設計をしているのか、と言う想定外テストが全工程の5割程度となります。

4.因みに可変長データを含むシステムの場合は、デバッグ自体が9割に達する場合もあります。

1.次に裁判の件ですが、裁判官が動いていればいいのですよね、と言っていると言うことは、質問者が被告に対し提出した訴状若しくは準備書面に、①デバッグの必要性②異常データ検知時のシステム対応について、契約上相手が責任を負う内容となっていない、と言う認識が発生しているからです。

http://www.cc.matsuyama-u.ac.jp/~tamura/minpo-709.html

2.当該訴訟については、民法第709条の不法行為損害賠償請求訴訟であると判断されますが、その場合ポイントとなるのが、民法第644条の善良なる管理者の注意義務です。

http://homepage3.nifty.com/mbcmis/sub13.html

3.論点としては、善管注意義務の履行確認として、デバッグテストの有無を被告が怠ったと言う不法行為を立証しているのが、デバッグの有無が、民法第644条で規定する善管注意義務違反であると言う論拠に結びついていないため、裁判官が動いているのでしょ、と質問者に対し口頭弁論時に確認を求めているわけです。

4.よって、今後の準備書面作成の論点としては、PG作成会社としてPGの適合性を確認する術としては、デバッグテストは当然に必要であり、当該テストが標準時間以内であることは、民法第644条で受託者が委託者に負う善管注意義務に違反するため、民法第709条の損害賠償責任が発生すること。

5.デバッグのテスト以前の問題として、当該PGに入力されるデータを事前に委託者と確認作業をし、異常データが発生した場合のシステム処理方法を明確化し、通常稼動状態では異常終了が頻繁に発生しないようにすること自体も、民法第644条で受託者が委託者に負う善管注意義務の範疇であり、通常稼動中に異常終了処理が多発すること自体、民法第644条で受託者が委託者に負う善管注意義務に違反するため、民法第709条の損害賠償責任が発生すること。

6.4並びに5の理由から被告には損害賠償責任が発生すると言う論理更正が妥当でしょう。

ソフトウェアエンジニアリング基礎知識体系―SWEBOK

• 出版社/メーカー: オーム社
• メディア: 単行本

ソフトウェアエンジニアリング知識体系－SWEBOK－

という書籍があります。

この書籍はその名の通り世に溢れるソフトウェアに関する様々な知識を体系化したものです。

この書籍の第5章ソフトウェアテスティングの5.1序説において、いきなり以下の記述があります。

テスティングは、ソフトウェア開発における、重要、かつ必須の部分である。

また、第2章ソフトウェア要求の2.3.5.4受け入れテストにおいては以下の記述があります。

システム要求に不可欠な特性は、完成したプロダクトが要求を満たしているかを表す、妥当性確認が出来なければならないことである。

これは、要求（仕様）は妥当性確認が出来るようなものでなければならない、ということなのですが、裏を返せば『プロダクトは妥当性確認によってシステム要求を満たしていることが表明される』ということですね。

システム要求が満たされて、プロダクトは完成となります。

件の業者は、システム要求を満たしていることを妥当性確認（テスト）によって表明しなければ完成したとは言えない、と言えると思います。

この書籍では、要求、テスト、品質等についても、その定義づけから記述がありますので参考になるのではないでしょうか。

質問１につきましては、定量的な記述がありませんでした。申し訳ありません。

質問２につきましては、ご紹介した記述からも『あり得ない』といえるのではないかと思います。

ご質問の趣旨からは若干外れるとは思うのですが、裁判ということなので、念のため回答をつけさせていただきます。

２　付随した質問になりますが、デバック、テストを行わない

ソフトウェア開発というものはありえるでしょうか。

情報科学の研究としてはそういう方法も提案されています。

プログラムの正しさをテストによって確認するのでなく、プログラムが正しく動作することを証明（三段論法とか、数学的帰納法とかをつかうあの「証明」です）することで確認するものです。

たとえば構成的プログラミング

http://www2.odn.ne.jp/yuseisha/oyohoka/koseiteki.htm

では、期待通りのプログラムが存在することを証明し、その証明の記述からプログラムを自動的に生成します。証明の正しさは自動的に検査でき、論理的に正しいプログラムが生成されることになります。

なお、このような方法を用いた場合には、正しさの証明を提示できるはずです。また、このような方法でプログラムを作ることは、たとえ簡単なプログラムでも、その分野の研究者の力をもってしてもかなり大変ですので、現実的とはみなされていないと思います。