2005年11月29日

Java Web Startアプリケーションのデバッグ

Java Web Start経由で起動するアプリケーションはデバッグが困難です。
javaを起動してデバッグできればよいのですが,javaws(Java Web Start)を起動しないとデバッグできない場合もあります。
javawsはjavaを起動するアプリケーションなので,javawsに設定をしてもJava Web Startを用いたアプリケーションはデバッグできません。
そこでリモートデバッグを使用します。WindowsでEclipseを用いた場合は次のようにします。
  1. 環境変数JAVAWS_VM_ARGSの設定
    環境変数JAVAWS_VM_ARGSで,javaws経由でjavaを起動する場合のオプションを指定できます。

  2. set JAVAWS_VM_ARGS=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=8200,server=y,suspend=n

  3. アプリケーションを起動
    デバッグ対象のアプリケーションを起動します。

  4. javaws http://localhost/test/test.jnlp

  5. Eclipseの起動,デバッグ
    Eclipseを起動し,デバッグのダイアログを開きます。
    「リモート Java アプリケーション」を選択し,「新規」を押します。
    「プロジェクト」にプロジェクトを指定し,接続プロパティーの「ホスト」に「localhost」,「ポート」に「8200」を指定します。
    その後,[デバッグ]を押すとデバッグできるようになります。
  6. remote.JPG

    おまけ。
    環境変数JAVAWS_TRACE_NATIVEに1を設定すると,java起動時のオプションを画面に表示します。
    オプションに何が指定されてるか知りたい場合にどうぞ。



posted by まる at 07:26| Comment(1) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2005年11月22日

保守の恐怖

他社が開発した案件の保守や、前任者から保守の仕事を受け継ぐことがあります。
まず最初に、「どうやって保守しよう・・・」と胃が痛くなります。
保守案件ではいろいろ痛い目にあっています。
顧客による検収も完了してから引き継いだ某案件。
システムの勉強がてらに仕様書とソースを比較してると、仕様書にある記述がソースにでてきません。 このシステムって開発終わったんじゃなかったっけ?と思いながら前担当に確認をとってみます。

「あのー。仕様書に記載してるDBとの連携機能がないんですけど…」
「えーっと。ホントだ。作ってないや。」

青ざめる筆者。前担当はお構いなしに話を続けます。

「ま、俺も別の開発で忙しいからどうにかしといてよ。」

機能がそっくりないのに,どうしろと。
なぜ機能が作りこまれてなかった経緯を調べたところ、該当機能は半年に一回しか使わない処理なので、顧客も前担当者もすっかり忘れていた模様。
話が違うと上司にかけあっても、前担当者は火消しとして別のプロジェクトに投入されたので、自分らでどうにかしろとのお達しが。 しょうがないので、顧客にバレないうちに休日出勤を繰り返してプログラムを作成し、別のシステム改修の機会にこっそりとプログラムを追加しておきました。
顧客にバレなかったから助かりましたが、バレたらどうなってたんでしょう。

posted by まる at 00:21| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2005年11月15日

バグと品質の関係(その2)

信頼度成長曲線とはテスト項目消化数や開発日付をX軸に、不良の累積件数をY軸に関連させてグラフ化する手法です。バグ収束曲線とも呼ばれます。バグ収束曲線の名のとおり,開発初期の頃から次第に不良件数が増加していき,テスト中はグラフの傾きが最大となります。顧客に納品するころには不良が出尽くして傾きが緩やかとなります。テストが進むにつれて不良の発生確率が減少するからです。顧客環境を意識したテストを実施していれば,テスト時の不良摘出率が減少すると,顧客環境での不良発生率も減少します。
不良摘出率の減少がグラフの傾きとして可視化されることから,直感的に品質を把握しやすくなってます。

経験的な指標として信頼度成長曲線を使用するなら問題ないのですが,納品基準に信頼度成長曲線を適用されるといろいろなドラマが発生します。 納期ギリギリでテストを行っていると,ついついやっかいなテストを後回しにします。やっかいなテストというのは,境界条件であったり,正常系の条件でも一般ユーザはまず使わないような値を使用しています。そのためやっかいなテストというのは高い確率で不良を発生させてしまいます。そうなると,最後に実施するやっかいなテストのおかげで開発末期に不良が集中します。 信頼度成長曲線が開発末期になって寝るどころか,元気よく成長するのです。そのため品質が安定していないと判断されます。
やっかいなテストが終わったので品質が安定しているにも関わらず。

ここに信頼度成長曲線の問題があります。信頼度成長曲線では日程やテスト項目ごとの重みを考慮しません。そのため,現場の実感と外れた結果が出ます。このへんの定性的な事情に理解を示してくれる顧客であればいいのですが,そうでなければ顧客とバトルです。テスト項目の見直しと追加を要求されないように頑張るのが管理者の職務となります。

納期ギリギリの開発状況をどうにかしろや,とか,やっかいなテストを前倒しで実施しろや,といった意見が聞こえてきそうですがその辺は無視の方向で。

posted by まる at 08:21| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年11月08日

バグと品質の関係(その1)

バグの話題が出たので,ついでにバグと品質の関係を触れてみましょう。

ある程度の規模のプロジェクトでは,品質管理基準が決められています。 よく言われるのがキロステップあたりの摘出目標件数と,信頼度成長曲線です。

キロステップあたりの摘出目標件数というのは,キロステップあたりの不良件数と摘出目標件数を比較により品質を確認する手法です。
摘出目標件数は過去の類似プロジェクトの経験などから設定します。だいたい 10件/Ks ぐらいでしょう。
摘出目標件数よりキロステップあたりの不良件数が少ないと,不良の摘出が足りないとみなされます。テスト観点を見直し,チェックリストを増量し,摘出目標件数に届くまでテストします。
逆に摘出目標件数よりキロステップあたりの不良件数が多いと,品質に不安があるとみなされます。なぜ摘出目標件数より不良が多いかを分析し,チェックリストを増量しテストします。

たとえば,3キロステップの開発に対し,テスト工程で42件の不良を摘出したとします。
この場合のキロステップあたりの不良件数は 42(件)/3(Ks) = 14(件/Ks) です。
つまり,10件/Ksの基準よりも不良が頻発しているので,不良の原因を分析する必要があります。
コードを書いたのが初心者だからとか,GUIを用いたプログラムなので不良がでやすいとか,マルチスレッドのテストが不足しているとか,適当な理由を考えます。
対策もベテランにソースコードをレビューさせるとか,GUIまわりの遷移を網羅的にテストするとか,マルチスレッドの状態遷移と資源のロック取得状態について表にまとめてテストするとか,適当な理由を考えます。

摘出目標件数より少なくても,多くても文句を言われるのがこの方法のミソです。キロステップあたりの不良件数が多い場合は適当な理屈をつけやすいのですが,少ない場合はテストが足りないと怒られます。

現在のキロステップあたりの摘出目標件数の問題点は,全体の統計情報に頼りすぎ,個別の状況を勘案していない点にあります。

実際にあった話ですが,Aさんというスーパープログラマの不良件数は2〜3件/Ksでした。腕がいいので不良がでないのです。
ところが,摘出目標件数よりも不良件数が大幅に少ないので品質が悪いということになり,顧客よりテストの増量を要求されました。
顧客とやりあっても,摘出目標件数より少ないの一点張りでラチがあきませんでした。そこで,最終的には不良を捏造して納品しました。それから数年たちますが,Aさんの担当した箇所から不良は1件も発生していません。

逆にマルチスレッドや,GUIがからむ部分は,不良が出やすく,摘出目標件数をオーバーします。

この問題の解決策として,筆者を指導した上司は,対顧客用の摘出目標件数と,プロジェクト/個人の摘出目標件数を分離して管理していました。過去の実績などを勘案して,プロジェクトおよび個人ごとに摘出目標件数を割り振るのです。
この方法は過去の実績が必要なので,どのプロジェクトでも適用できるわけではありません。しかし,いったん適用できれば,プログラマの実感に近い数値が摘出目標件数となるので,プログラマにとっては納得しやすい数値となります。

筆者も自分がプロジェクトを管理するようになってから実施してみました。やはり,顧客をちゃんと納得させるかがカギです。顧客を納得させるためには過去の実績が必要なので,実績を蓄積して計算する必要があり,結構苦労しました。

分量が多くなったので,信頼度成長曲線の話は来週にします。

posted by まる at 06:39| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は180日以上新しい記事の投稿がないブログに表示されております。