年末にちょっと触れたオオカミ少年の考え方にちょっとふれてみた。
シミュレーションすると、わかりやすい。
でも、全部手書きw
便図をつかって表現
ベイズの定理をつかってみる
シミュレーションするとこうなる
次回は本当にscarabつかってやってみようかな。
このエントリは、以下の本を参考に書きました。
「岩波データサイエンス vol1」
https://www.amazon.co.jp/岩波データサイエンス-Vol-1-岩波データサイエンス刊行委員会/dp/4000298518
わかりやすくて、薄くて内容の濃いとてもいい本です♪
今回は、数式は書かずに導入だけ触れることにします。
自分の頭の整理のために・・・。
簡単に言うと、下のようなイメージになる。
ベイズ統計は、データだけではなくてデータの背後にある要素も確率的に生成されると仮定する。
ベイズ統計を理解するのによく使われる例は、
「オオカミ少年」の事例でしょうか。
上記を「仮定」の条件にして、次に起こりうることを推定する。
嘘つきならば、次に本当のことを言う確率や、うそをつく確率などを用いて求める。
これを考えると、「人狼」というゲームがありますが、データを取得していけば、予測できそうですね~。
結局、一般化すると、
「母数の事前分布」+「検査データ」 ⇒ 「母数の事後分布」
ということになります。
2018/2/17に、川崎でベイズ統計の勉強会をひらこうかなと思っております。
ご興味のある方は、connpass立てますので、ぜひご検討くださいませ♪
では、よいお年を~。
もう2017年もあと1日と半分。
はやいなぁ、と・・・。
NaITEのスタッフになってから2年がたとうとしています。はやいなぁ。
ということで、個人的に振り返ります!
今年は、勉強会を7回も開いていました。2か月に1回のペースで企画していたのですが、なんだかんだで7回。スタッフも頑張っています!
NaITEは、AgileJapan長崎サテライトや、秋~冬にかけて長崎QDGという大きなイベントも開催しています。
主査の池田さんをはじめ、スタッフのしょーごさん、くまきちさん、つのだくん、ふじさわくん、まつやまくん、てしまくん、うじたくんと皆でがんばっています。
みんな、それぞれの想いを持って活動をしています。
仲もよいけど、礼節もきちんとしている。そんな仲間と出会えてよかったです。
個人的にも、数学勉強会を開いていくことにしました。
ただ数式を追いかけるだけだとただの苦行にしかならない。どうすれば数学を楽しめるかな?これは何に使われているんだろう?どうつながっているんだろう?
そんな目線から、いろいろとご紹介していけるといいなぁとおもっています。
一緒に勉強したい方、声をかけてくださいね!
2017/1/21 NaITE#19 「数学を学ぼう ~数学の知識を利用したソフトウェアテスト~」勉強会
数学のパート。ただ、数式を展開するだけの勉強会ではなく、何に使うのか、どういう場面で何(数式・考え方)が使えるのか、というアプローチでの勉強会を開催しました。
JaSST TOKYO 2017 で、コミュニティブースをだしました!
こういう試み初めてでした。NaITEを多くの人に知ってもらえる機会を得ることができて、本当に感謝です。
JaSSTソフトウェアテストシンポジウム-JaSST'17 Tokyo
ちなみに、ここで事例発表を行いました!(自社の事例発表です)
「品質予測モデルの構築およびプロジェクト管理への適用事例」
2017年4月8日 NaITE#20「プロセスモデル CMMI にまつわるちょっと深イイ話」 勉強会
CMMIというプロセス参照モデルのご紹介をしました。
プロセス参照モデルを使うには、道具(CMMI)を知っている必要があり、詳細を中村こーじくんが紹介してくれました。そして、そのプロセス参照モデルを組織でちゃんとまわしていくためにはどうするか?という視点でのご紹介もさせていただいております。
2017年4月22日 NaITE#21「PSP概説&体験ワーク(おかわり)」 勉強会
これをしっているかしらないか、で、業務の改善度は格段に違うと思います。
その内容のご紹介を、くまきちさんがしてくれています。
2017年5月20日 NaITE#22「はじめてのバグ票システム~導入実践ガイド」 勉強会
ソフトウエア開発にかかわる人は、バグとはきっても切り離せない。そんな情報を取り扱うためには、何が大切なの?バグ票ってなんのためにあるの?といったところからも、バグ票システム導入実践ガイドご紹介しています。
この回には、細川さんが来てくださいました!
医療とソフトの近さを感じるご講演をいただきました。
2017年7月16日 NaITE#23 「Scrum入門&Agile Japan 2017 長崎サテライト参加報告」 勉強会
アジャイルしばりの勉強会。AgileJapanの参加報告と、Scrumとは?について、きんじさんにご紹介いただきました!
2017年9月17日 NaITE#24 「テストカタマリー ワークショップ&解説」 勉強会
テストカタマリーのワークショップを、みずのりさん、くっきーさんに開催していただきました。
テスト設計時にモデリングをして、テストをする人・開発をする人・顧客の視点などからの気がかりなところもそのモデルに関連付けておけば、なんでそのテストをしたの?というところの根拠にもなるなぁと個人的には思っております。
2017年11月11日 NaITE#25「欠陥モデリングワークショップ&解説」 勉強会
森りゅうじさんに、欠陥モデリングのワークショップをしていただきました。
5月に開催いたバグ票とあわせて、バグの内容をモデリングして抽象化すると組織の資産としてかなり有用性の高いものになるので、両方をしっておくとすごくいいなぁと思います。
来年は 1/20にNaITE#26、2/2に長崎QDGを開催予定しています。
ぜひぜひご参加下さい!
来年もどうぞよろしくお願いいたします。
2ヶ月ほどまえに参加したセミナーについて、ブログってみました。
有料だったのでどうかなと思ったのですが、にしさんから許可(?)もらったので、掲載しちゃいます。
非常に費用対効果が高いセミナーでした。こんなセミナー、もうないんじゃないかなぁと思うほどの満足度の高さです。ありがとうございました。
森崎さんの講演で、「チェックリストは「やり方が」書かれていない。どうやってそれを確認するのか?が書かれていない。」というお話がありました。
社内でも、「ツール」を使った、そのツールが**です、という報告はあるが「どう使われたのか、使った目的は何か」というところに触れられていないことがあるのとリンクするなぁと思いました。手段・方法は、プロセス・目的と一緒にセットで情報を持っていないと意味がない。そう思いました。
細谷さんの講演では、グランドルールありき、チームビルディングありきの改善かもしれない、とおしゃっられていたことが印象的でした。
個人ではなくチームでルールを作り、自分たちで決めたことは守る、ということを厳しく貫いているところがおおきな成功要因なんだなぁ、と思います。
パネルディスカッションを見ることが一番の目的でした。ここだけで、もう本1冊分の価値があったのではないかなぁと思うような内容でした。「レビュー」と「テスト」って、似て非なるもの。そこを痛感するパネルでした。
ソフトウェアの品質向上のため、要件定義書や設計書などワークプロダクトのレビューは重要です。2017年2月にISO/IEC 20246:2017 (ワークプロダクトレビュー)がレビュー技術やプロセスを定義する国際標準として発行されました。
本セミナーでは、このISO/IEC 20246:2017発行を機会に、レビュー技術や事例、また標準化最新動向を紹介・解説します。まず、レビューの技術やプロセスについて一般的なものから最新情報など、また、産業界での適用事例を紹介します。さらに、ISO/IEC 20246:2017の解説を行います。最後に、パネルディスカッションを行い、レビュー技術の事例や国際標準の意見交換を行います。
ソフトウェアプロダクトレビューは実行可能なプログラムが存在しない時点でも実施できる欠陥検出技法です。本講演では、ソフトウェアプロダクトレビューの基礎と研究動向を紹介します。ソフトウェアプロダクトレビューの基礎として、目的、参加者の役割、欠陥の検出例を示し、ソフトウェアプロダクトレビューの原理を理解いただきます。次に、検出した欠陥を早期に修正することによって得られる欠陥の修正コストや欠陥の見逃しリスクの低減といった効果を解説します。最後に、これまで研究分野で議論されてきたソフトウェアプロダクトレビューの技法や技術を紹介した上で、近年注目を浴びているModern Code ReviewやArchitecture Tradeoff Analysis Methodを紹介します。
ソフトウェア開発において、ドキュメントやコードのレビューは、品質向上のために重要な活動ですが、開発現場では、レビューに投入したコストに見合った効果が得られている実感がないという課題がありました。そこで、レビューで検出したい欠陥を明確化し狙いに合わせたレビューの実施時期、実施方法を定めることにより、開発現場が効果を実感できるレビューに改善しました。本セッションでは、レビュー観点の分類、レビュー技法の使い分け、実施シナリオなど改善活動の中で定めた実施方法について紹介します。
パネラー:森崎さん(森)/増田さん(増)/細谷さん(細)/西さん(西)
⇒森:レビューは社風が出る。けん制しあって向上するという文化とか。文化が異なる同士のレビューはそれぞれ違和感を感じるだろう。
以上!
ソフトウェアテスト アドベントカレンダー 12/21担当のあさこです。
テスト実施時には、バグが想定通り(?)に出ているかどうかのメトリクス分析を行う方は多いと思います。
割と、そこでベンチマークとして使われるのが、IPAから発行されているデータ白書。
参考:SEC BOOKS:ソフトウェア開発データ白書2016-2017:IPA 独立行政法人 情報処理推進機構
ここで多く使われているのが、二つのメトリクス(変数)を散布図で表し、回帰分析結果とその信頼区間(50%、95%)を算出したグラフです。
多くの企業が協力しているデータなので、ベンチマークには最適です。
以下例です。
出典:https://sec.ipa.go.jp/files/secbooks/000057880.pdf
自社にて、部門間ベンチマークを行う際にも同じようにできるといいですよね。
Excelで分析のできるツールがIPAで公開されており、サイトからダウンロードできますが、ツール内でどんなことをやっているか、気になりませんか?
内容を一部ご紹介します。
ぜひ、自社のデータでも試していただけると幸いです。
メトリクスを取得する目的と、メトリクスの間の関係式を微分方程式で示すことを簡単にまとめたブログです。
IPAのデータ白書で散布図を用いて分析・表現されているものには、いろいろなものがあります。
基本的には以下のメトリクスが挙げられます。
これらそれぞれの数値同志の相関をみて、その相関係数にて、上記ブログ内にある4つのタイプからその現象を説明する式を選択します。
今回ご紹介しようとする例は、
を使って考えていきましょう。
「基本のおさらい」で取り上げました内容に従い、メトリクス同士がどの微分方程式の関係性の時が相関が高いかを見ます。
自社のデータをもとに試したときは、以下の4タイプのうち、4のものが多かったので、それをとりあげます。
回帰分析して求めた結果を使用する。
近似式の求め方は、Excelだとこんな感じ。中に書かれている値は、例です。
数式で説明すると、こんな感じ。
# ①データの読み込み
WhitePaper.data <- read.csv("testdata.csv", header=T)
head(WhitePaper.data) #読み込んだデータを確認
LIN <- WhitePaper.data$Line
TH <- WhitePaper.data$TotalBug
#②散布図のプロット
plot(log10(LIN),log10(TH)) # 生産量(LIN)と総工数(TH)
#③回帰分析
# lm関数に、説明変数をLIN、被説明変数をTHとして代入
result <- lm(log10(TH) ~ log10(LIN))
# 分析結果の要約
summary(result)
abline(result) # 回帰直線を描く
#④対数スケール(回帰直線)⇒もとのスケール(回帰曲線)にもどしてグラフを描く(データを重ねがき) #####
##summary(result) の結果から係数をもってくる。
# 回帰分析の結果 log10(y) = 2.4615 + (0.8331)*log10(x) より
x <- 0.01*c(0:7000)
prediction <- 10^(2.4615)*x^(0.8331)
plot(x, prediction , col=2,type="l", xlim=c(0,70), ylim=c(0,11000),
xlab="", ylab="", main="")
par(new=TRUE)
plot(LIN, TH, col=4, xlim=c(0,70), ylim=c(0,11000),
xlab="LIN", ylab="TH", main="")
###### 信頼区間
alp2 <- 0.05 # 有意水準alp/2 ⇒ 信頼係数1-alp ⇒ 95%信頼区間のとき alp=1-0.95
# 95% のとき alp2 <- 0.025
# 90% のとき alp2 <- 0.05
# 50% のとき alp2 <- 0.25
n <- length(LIN) # データ数
bar_log <- sum(log10(LIN))/n
y_hat <- 10^(2.4615)*LIN^(0.8331)
# 残差分散の平方根
s <- sqrt( 1/(n-2)*sum*1^2) )
### 信頼区間の計算
C <- sqrt( 1/n+(log10(x)-bar_log)^2/sum((log10(LIN)-bar_log)^2) )
K <- 0.8331*log10(x)+2.4615 + qt(1-alp2,n-2)*s*C
confidence_U <- 10^K
K <- 0.8331*log10(x)+2.4615 - qt(1-alp2,n-2)*s*C
confidence_L <- 10^K
plot(x, confidence_U, col=3,type="l", xlim=c(0,70), ylim=c(0,11000),
xlab="", ylab="", main="")
par(new=TRUE)
plot(x, confidence_L , col=3,type="l", xlim=c(0,70), ylim=c(0,11000),
xlab="", ylab="", main="")
par(new=TRUE)
信頼区間95%の時と、50%の場合を両方求めてプロットしました。
いろいろとアレなので、メモリの数字などはとっぱらてありますw
メトリクスは扱いを間違えるとアカンことになります。
我々の仕事で言えば、コンポーネントテストで見つかった不具合とシステムテストで見つかった不具合の件数を足したり、それらを合わせて使ってソフトウェア信頼度成長曲線を描くひとはいまだに多いですよ。
— あきやま🍻 (@akiyama924) 2017年12月20日
②について、例えば因数分解の問題で係数が違うだけとかなら、平均を取る意味はあると思います(教え方を変えた結果を測るなど)。
— あきやま🍻 (@akiyama924) 2017年12月20日
そうではなく、因数分解と確率計算の問題なら、それは①と同じく平均を取って比較するのは間違いだと思います。
取得方法が同一で、同じ単位。
— あさこ (@acha_821) 2017年12月20日
そういうものが同じ土俵で比較することができる、という原理に基づくなら、やっぱり違うテストレベルのバグ件数は足し合わせないほうがいいんだろうなあ。
ノイズとかそんな話ではないからなあ。
たまたま、この記事を書く前日にこんな感じのやり取りをしたので、参考までに。。
数値データの裏の背景などのにも目を向けて取得してつかわなきゃ~とおもいました。
ここまでお付き合いくださり、ありがとうございました!
*1:log10(TH)-log10(y_hat
メトリクスは、何かをおこなったときの効果を定量的に測るツールになるので、「必ず」取得するための目的があります。
そして、その目的を支配する法則があるのではと私は考えています。
その法則を見出すには、微分方程式から入るのが一番簡単だと思います。
現象が説明変数xと被説明変数yで記述できると仮定します。
簡単にするために、2次元で考えます。
yとxの微分方程式では、その間にある変化量を見ることができます。
なので、データは、以下の3つの微分方程式で表すことができます。
それぞれの微分方程式を解くと、右の式になります。
基本形なので、すべてがこれというわけではなく、派生形も存在するということは付け加えさせていただきます。
現象が数式で表せるということにより、以下のような嬉しいこと(笑)もできるようになります。
ソフトウェアテストの小ネタ 12/10担当のあさこです。
小ネタなので、すぐにできそうなところからご紹介♪
テスト対象のリスク度分析の一例を二つほど、ご紹介します。
ソースコードメトリクスを利用します。
ソースコードメトリクスは、いろいろなツールで取得可能です。
その中から、一つ目のご紹介。
皆さんも使われている方も多いと思いますが、
を使用したテスト対象のリスク分析です。
すごく簡単。
一般的に、15を超えると保守性が低い傾向があるといわれており、バグが潜みやすい傾向にあるようです。
なので、以下のような策をとられるとよいかもしれません。
その際にはもちろん言うまでもありませんが、意味があって複雑度が高くなっているのか、それともコードを書いた人のスキルなのか、なども合わせて考慮する必要があります。
すぐにできることなので、参考になさっていただけると嬉しいです。
二つ目のご紹介。
以下のメトリクスを利用。
これは、Understandというツール
ソースコード解析ツール Understand | ソフトウェア品質保証 | テクマトリックス株式会社
から取得することができます。
Essential、Fanin・Fanout(二つのメトリクスを掛け合わせた値)このふたつをx,y軸に取り、散布図を描きます。
このメトリクスのプロットの意味するところは、もう想像がつくと思いますが、関数が複雑なうえに入出力値まで多ければ・・・そうです。ご想像の通りです。。。
ということで、判断基準としては、
Essentialの値が10以上、Fanin・Fanoutが400以上で囲まれる範囲を高リスクゾーンとし、集中的にテストを行う。
ということを一つの事例として紹介させていただきます。
以下のスライドの15ページ目でも、ご紹介しています。
少しでもプロダクトの性質・特性を把握できれば、メトリクスの値と一緒に分析して品質を作りこんでいくことが楽になるかもしれません。
このサイトにも、ソースコードメトリクスを利用した分析の事例が掲載されています。
このメトリクスを取得できるツールは、有償無償だと、私が知っているところでは以下のものがあります。
有償:Lattix (テクマトリックス社取り扱いソフトウエア)
無償:ccfinder(32ビット版しかないかも・・・)
取得できるメトリクスはかなりたくさんあります。
また別の機会に、このメトリクスを利用した事例をご紹介したいと思います。