第8回SQuBOKユーザ会勉強会にトーカーとして参加します。

バグ票コミュニティ(「バグ票ワーストプラクティス検討プロジェクト」)として、
第8回SQuBOKユーザ会勉強会に参加します。
当日は、今までアンケートでいただいた事例紹介を中心に
コミュニティの紹介や今後の活動などについてお話したいと思います。
コミュニティのアウトプットとしては、まだまだかと思いますが、
みなさまのご意見を伺えればと思います。

広告

第6回SQuBOKユーザ会勉強会に参加してきました。

2013年2月14日に、第6回SQuBOKユーザ会勉強会が開催されました。

http://kokucheese.com/event/index/55470/

ご参考:SQuBOKユーザ会については以下のサイトを参照すると良いと思います。
SQuBOKユーザ会ポータルページ  Facebookファンページ

今回は、小池さんと堀さんのお二人がトーカーとして発表なさいました。
参加のメモ書きを兼ねて内容を簡単に書いてみます。

小池さん:「品質保証活動(SQA)を形骸化させないコツ」

プロセスが形骸化する理由

  • 「ルールで決められているから」「規準に書かれているから」とルールを強いる。

プロセスはルールではなく、道具である。「決められているから実施する」のではない。
プロセスは、
プロジェクトの失敗の予防に役立つから使う。そして使う以上はうまく使えるようにする。

  • 「開発がxxxx(プロセスなど)をしてくれなくて困る」と言ってしまう。

「データを提出する」「資料を作成する」するという作業は、プロジェクトに恩恵をもたらさないと認識する。

  • 「手順書や帳票を使ってくれない」

手順や、帳票を、現場に使ってもらえる努力をどれくらいしているか。
スタッフはサービスは精神が命であり、悪い点使いにくい点があれば、どんどん直していくこと

  • 適切なマネジメントのうえで,はじめてSQAが生きる
    目標はQCD達成だけでなく、チャレンジも盛り込むようにする。チャレンジ項目に対する評価を行なう。
    改善に対する評価がなければ、改善に対するやる気があらず、目の前の仕事しかしなくなる。
  • 「プロセス」「スタッフ」「マネジメント」のあり方の問題
    ロジェクト成功のためのサポートになるようにする。プロジェクトの成功に寄与しないと判断したならやめる。
  • 形骸化になる理由
    「開発者が、その活動がプロジェクトの成功に寄与しない」、と考えているから。
    →スタッフは貢献できているか自問自答しながら活動する必要がある。
    中長期的な組織の成長があっても、まず目の前のプロジェクトの成功させることをしないとだめ。
    悪いところだけを指摘するのではなく、いろいろな相談に乗ったり、改善案を検討したりすることが重要。

まとめ

プロセス改善に魂込めるには以下の様なことが必要である。

  • プロセスやルール、帳票などを使ってもらう努力を行なうこと。
  • 淘汰されたものは潔く諦める
    必要と判断して、残したものはまめにメンテナンスを行なう。
  • パイロットプロジェクトで試行する。
  • 常にプロジェクトの成功を考える
  • 客観的な姿勢でのぞむ

議論内容

  • メトリクスで人を評価してはいけない。人を評価するようになると正直なデータが出てこなくなる。
    人ではなく、プロジェクトという単位でみるようにする。
    人ではばらつくことがおおいが、プロジェクトという単位なら相殺されてぶれが大きくなくなるときがある。
  • 「プロセスを守りなさい」だけで縛ってはいけない。
  • プロセスの目的を考え、目的と合致しているかどうかを考えること。
  • プロセスは状況に応じて変化させていくこと。
    プロセスの標準化は、改善のためのベースラインを決めることである。決めたところからどう変えるかを考える。
  • SQAは、上位マネージャなどが判断するための情報を情報を提供するようにする。

堀さん:「ソフトウェアメトリクスの単位」

なぜメトリクスか

何かを定量的にあらわそうとすると、そのモノの本質をよく考える必要に迫られる
「神棚計画」のように、一度作成された計画の見直しがされないのはダメ。
「見積もり」→「実施」→「分析」→「見直し」といったようなサイクルを回すのが重要。

書籍「<はかる>科学」

書籍の紹介:「<はかる>科学」

http://www.amazon.co.jp/gp/product/4121019180

いろいろな「はかる」について書かれた本。
現代ではかることが難しいものに、どう向き合っているのかがわかったりしておもしろい。

本からの紹介例:
18世紀フランスで使われているいろいろな単位は群毎に異なっていた
→いまのソフトウェア開発で用いられている様々な尺度も同じような状況ではないか。

ソフトウェア開発における「はかる」

  •  step/人月
    • そもそも、コード書かなくて作成できるアプリケーションには、SLOCが登場しない
    • 保守性や移植性などを考慮されたプログラムはどうか
      よく考えられたプログラムが生産性が悪くて、コピペだらけで作成されたソフトウェアのほうが生産性がよいという評価は適切か?
    • 短時間でたくさんコーディングすれば生産性が高いのか?
    • そもそも人月って意味があるのか?
    • なぜSLOCか。

再利用しやかった。またそれしか有用な指標がなかった。新たな指標が望まれる。
Capers Jones:「SLOCではかることはゴムのように伸び縮みするものさしではかるようなもの」

  •  テスト項目数/step
    • 1件はどうカウントする?
      • Excelで書かれたテスト手順の1行が1件か?
      • マトリクスのテスト手順書はどうカウント?
    • 1つのテスト項目に複数の確認項目がある場合はどうする?

ここでは、「step/人月」「テスト項目数/step」をあげたが、他にもいろいろ似たような曖昧な指標があるはず。

単位を厳密に定義するのではなく、首尾一貫していることが大切。
→厳密に定義しないと、定義できないのではないか?

ワーキンググループの提案

ソフトウェアの様々な規模尺度や生産性を活用方法、定義、表し方、収集方法について検討するWGを立ち上げようと思っている。
期間は1年。成果はSQuBOKユーザ会やSQiPシンポジウムで発表したい。
・定性的情報/定量的情報の両方が必要
・定性的情報を、定量的には把握し、確認、裏付けをする
・定量液な情報から、定性的な情報を引き出す

議論内容

  • 因果関係をみながら対処することが重要
    レビューでよばれたとき、つくってきたもののモデルのつじつまがあっているのか?をみた。
  • モデルの厳密性や妥当性を示す、メトリクスはないか?もとのモデルが正しいか知りたい。
  • プロジェクトのわるいところは、数値を見なくても、プロジェクトを直接みることでだいたいわかる
    数値は、追認するときにつかう。
  • メトリクスの妥当性の範囲はわかりにくい。
    なので、異常値に着目することが多い。
    特性(くせ)をさっぴいて、極端に変な値になっていないか?
    →そこで悪いような値はかなりわるいケース
  • メトリクスは、「なににつかうの?」からはじめる必要がある。
    先にメトリクスありきで活用方法を考える、はおそらくうまくいかない。

次回予定

2013年3月21日(木)ということですので、ご興味ある方は、参加検討されてはいかがでしょうか。
トーカー(発表者)は募集中のようです。

ご参考

第6回SQuBOKユーザー会勉強会つぃーとまとめ
http://togetter.com/li/456060

「(ソフトウェア品質技術者のための)データ分析勉強会第7回目」に参加してきました。

【2013/1/31 13:30 小池さまより内容についてのご指摘があり、一部の内容を修正いたしました。】

1/18に東洋大学で行われた「(ソフトウェア品質技術者のための)データ分析勉強会第7回目」に参加しました。

今回のテーマは「プロダクトメトリクス」でした。プロダクトメトリクスとは、勉強会概要のページにも書かれていますが、「レビューやテストといったプロセスではなく、製品の特性を測定するメトリクス」です。この「プロダクトメトリクス」をRなど統計解析ツールを利用して分析することを行なうのが今回の勉強会でした。( すずき註:Rについては以下を参照するとよいかもしれません→ 「実践!Rで学ぶ統計解析の基礎」)

この勉強会では「データ指向のソフトウェア品質マネジメント」(通称:「デート本」 以下「デート本」と表記)をベースにして行われました。

測定する対象

まずは講義パートです。

デート本「6.3 規模の測定」を参照しながら、「何を測るべきか?」についてお話しました。LOCの場合、コメント文は対象に入れるのか外すのか?C言語の場合、includeファイルのカウントはどこでカウントするのか?などといったお話がありました。

プロダクトメトリクス

デート本「4.3 欠陥修正が生じやすいモジュールの予測」を参照しながら、以下のようなメトリクスの意味などを確認していきました。

  • TMLOC(Total Method Libe of Code:総メソッド行数)
  • WMC(Weight Methods per Class:重み付きメソッド数)
  • CBO(Coupling Between Object Classes:結合度)
  • LCOM(Lack of Cohesion in Methods:凝集度の欠如)
  • RFC(Response For a Class:応答処理の多さ)
  • Modify(修正の有無)

また以下のサイトを参考にして、凝集度や結合度について確認しました。

凝集度と結合度
http://homepage3.nifty.com/koha_hp/KeyWords/KW.Coupling.html

複雑さのメトリクスという意味では、以下のサイトも参考になります。
http://se.naist.jp/lecture/se3/2006/handouts/productmetrics2.pdf

ツール

さて、実際にプロダクトメトリクスを視るときに、ソースコードを逐一手で計算することはありえなません。というわけで、測定ツールをつかうことになります。ここでいくつかのツールの説明をしました。

  • QAC
    ソースコードの静的解析ツールです。ライセンス料金が少し高いです。
  • Adqua
    ツールの出力結果のメトリクスだけ見せられても、良いかどうか判断出来ません。Adquaの場合、出力結果を送ると、無駄なコードの有無や警告数などから、コードの品質を、信頼性・効率性・保守性・移植性・再利用性 という観点で100点満点で評価をしてもらえます。メトリクスの範囲も、システム/モジュール/ファイル といろいろな範囲で取得可能なようです。無料で使用出来ますが、最低年1回のデータ提出することや、組込みプログラム限定といったいくつかの条件があります。

ちなみに、私は、以下の様なツールを使ったことがあります。

Sourceonitorは扱いやすいのでよいかもしれません。 CCFinderXは、コードクローンを調べるためのツールですが、メトリクスも出力してくれます。ただ、Phythonの設定とかに手間取り苦労したような気がします^^;

データ分析時の留意点

午後になり、演習パートになりました。

データを受け取った時どのようにアプローチするかを決めなかればなりません。

たとえば、特定のメトリクスに着目し、1つまたは2つ以上の変数に着目して、あるいはある値を基準にグループ分けを行なうようなアプローチや、このようなサイト( http://aoki2.si.gunma-u.ac.jp/FlowChart/Tutorial.html ) に従いアプローチを決める方法などがあります。

とりあえず、以下の様なことをするとよさそうです。

  1. 散布図行列を出力する。
  2. 外れ値やおかしなデータがないか確認する。
    工数やバグ件数など、手で入力するようなデータはおかしなデータがはいりやすい
  3. 各変数自体の分布を調べる
    偏ったりする場合には、対数変換などのデータ処理を必要があるかどうかを考え
  4. 相関があるかどうかを視る
    目的変数と相関が強いものが説明変数の候補となる説明変数候補同士で相関があるかどうかを確認する。
    相関がある場合は、両方は不要なのでどちらかに絞るかを考える。

他にも以下の様なお話がありました。

  • レンジの幅が大きくしまうようなソフトウェアメトリクス時に、等分散性を確保するための補正手段として対数変換を行なうことがある。そのとき、値が0だと定義できないので、インパクトの与えない程度の補正(下駄をはかせる)は手段としてはあり。
  • 寄与率(重相関係数)、自由度調整寄与率(重回帰分析)をみて50%程度では一般的にあまり良いとはいえない。
  • 一般的にデータが多ければ、検定結果のp値は小さくなる。従って検定結果だけでは、モデルの精度を判断することが出来ないので、寄与率などの指標も見る必要がある。
  • 検定はデータが少ない時につかう。データが多い時にはあまり使わない。

外れ値の精査を行なうことは、データ解析結果をきれいにするためには必要なようです。どれくらいやればいいかは、また外れ値の扱いも、ケースバイケースになり難しいようです。うーん、難しい・・・。

 データやデータ間の相関などは、経験の差が出るようで、繰り返し・継続してやってみてセンスを磨くしかないようです。

次回予定

次回は、2013年2月16日(土)に実施予定。内容は、いろいろな分析手法を手を動かしながら試してみよう、ということになるようです。是非ご興味ある方がいらしゃいましたら参加してみてはいかがでしょうか。

(2013/1/21 21:12追記)

「(ソフトウェア品質技術者のための)データ分析勉強会第8回目」の参加申し込みが可能になっています

http://kokucheese.com/event/index/71408/

告知

講師の小池さんより以下の様なアナウンスがありました。ご参考までにお知らせします。

  • ソフトウェア品質のホンネ
    SQiPポータルサイトから参照できます。ソフトウェア品質の世界で著名な方々が執筆されてます。
  • 2/25 SQiP特別講演「データ指向のソフトウェア品質マネジメント」
    次年度はセミナーを予定しているのでその説明をします。参加費5000円(本付き8000円)ですので、ご興味あればぜひご参加くださいとのこと。
  • 2/14 第6回SQuBOKユーザ会勉強会
    小池さんと堀さんが講演なさいます。会場は、日科技連 千駄ヶ谷の講堂ですが、Ustreamで配信も行います。小池さんのテーマは、SQA活動についてで、以前実施されたIPASECの講義を元にするそうです。
  • 来年度のSQiP研究会で「メトリクス演習コース」を開設します。
    小池さん、小室さん、野中先生で演習コースを行なうとのこと。カリキュラムとしては3フェーズとし、メトリクス収集活動の明確化、ツールを利用した統計解析の習得、事例適用を想定しているようです。興味ある方はぜひ参加してくださいとのこと。