品質関連
昔のメモ転記。
2009/10/31-
◆品質とは
（大辞林）
品物の質
（ISO・JISの定義）
明示または暗黙のニーズを満たす能力に関する、ある"もの"の特性の全体
（PMBOK）
要求事項への適合と使用適合性
プロジェクトでは、作成すると約束したものを作成し、
その成果物で顧客満足を実現すべき
（QMS / ISO9001）
顧客満足を得るために仕事をきっちりやる仕組み
◆ソフトウェアにおける品質
「品質の良いソフトウェア」とは
昔：当たり前品質 今：魅力品質
「品質＝障害がないこと」 「品質＝ユーザー満足度」
「当たり前品質（または後向き品質）：
ユーザーから見て、その製品が当然備えているべき品質特性
「前向き品質（または魅力的品質）」
プラスアルファの魅力が備わったもの
ユーザーの使い勝手の良いシステムを提供できて、
はじめて品質の良いソフトウェアと言える。
最初にきちんとした品質基準書を作り、
前向き品質をきちんと品質目標に組み入れ、
メンバー全員で共有することで使いやすいソフトウェアが作成できる。
ソフトウェアの品質とは、バグの少なさだけではない。
機能や魅力、市場への素早い提供まで含めて、
顧客満足度こそが品質。
◆ソフトウェア品質の視点
ソフトウェアのライフサイクルと品質の視点（ISO 9126-1/JIS X 0129-1)
・利用時の品質
利用者の視点でのソフトウェア製品の品質。利用者の必要性に合致するかどうか
・外部品質
ソフトウェアが実行されるときの品質。テストデータを用いたテストの結果（実行時のコードの振る舞い）など
・内部品質
ソフトウェアの内部的な特徴。ソースコード、仕様書なども対象。モジュール性（ソフトウェアが適切に構造化され、変更、修正などが局所的なもので済むようになっている性質）や追跡可能性（要求から実現されたものへの関連、および実現されたものから要求への関連を追いかけることができる性質）など。
・プロセス品質
設計／開発のやり方や手順の品質
ISO9001の『品質マネジメントシステム』は、プロセス品質に近い意味合い。
製品の品質そのものでなく、顧客の要求する製品を提供するシステムをつくりあげる、ということ。
◆ソフトウェア品質特性（外部品質、内部品質）
（ISO 9126-1/JIS X 0129-1)
機能性
ソフトウェア製品の能力のこと。
暗に期待されている必要性が含まれる。
信頼性
狭義の平均故障間隔などで示される概念だけでなく、
ソフトウェアに潜在していた障害による誤動作からの回復、
ならびに障害に対する許容性に対する概念も含まれる。
使用性
いわゆる「使い勝手」、「使いやすさ」、「操作性」。
効率性
いかに速く処理できるか、いかに資源を有効に使用するか。
保守性
修正のしやすさ。
移植性
別の環境へどれだけ容易に移せるか。
◆利用時の品質特性 (ISO/IEC 9126-4)
有効性
正確かつ完全に、指定された目標を達成できるソフトウェア製品の能力。
生産性
達成すべき有効性に対応して、適切な量の資源を使うことができるソフトウェア製品の能力。
資源には、作業を完了するまでの時間、利用者の労力、材料または使用した費用を含めることができる。「人的資源」に関する効率性は、こちらに含まれる。
安全性
人、事業、ソフトウェア、財産または環境への害に対して、容認できるリスクの水準を達成するためのソフトウェア製品の能力。
リスクは一般に、機能性（セキュリティを含む）、信頼性、使用性または保守性の欠陥の結果。
満足性
利用者を満足させるソフトウェア製品の能力。
◆ソフトウェアの品質状態の把握
・バグ曲線
一般に、1日当たりの障害発生数はテストの初期段階から急激に増えて行き、ピークを迎えてから徐々に少なくなる
発生数が十分小さくなった段階で品質が良くなったと認識する
障害が最初から少なく、ピークを迎えない場合は、テスト方法やテスト者の技量不足が考えられる
・障害の発生原因
障害の発生原因に"単純ミス"が多いうちは、まだまだ品質は悪い状態
品質が向上するにつれ、"複合原因"などのように複雑な要因でしか発生しない障害が中心になってくる
・障害の重大度
大きな障害が発生している状態ではテスト完了できない。
◆バグの対処
トリアージ：バグを対処するか、無視するかを決める
リソースが限られるため。
＃一般的には、トリアージとは、時間的・資源的制約があって
任務や課題のすべてを実施・完了できないとき、
一定の基準に従って着手の優先／非優先を判断すること。
通常、災害医療などで使われる言葉で、傷病者（患者）を
重症度と緊急性によって選び分ける作業をいう。
◆品質メトリクス測定
欠陥を「テスト」で捕らえるだけでなく、
欠陥の兆候を事前に捕らえる。
⇒テスト範囲を狭めて効率と効果を高める、
欠陥予防と欠陥計測に役立てる。
欠陥密度の絶対値では品質を評価できない。
プロジェクト規模、アプリの複雑度、開発者スキルなどに依存。
欠陥重要度別の残存バグ積み上げグラフ
◆
テスト手法とテスト技法
- ブラックボックステストとホワイトボックステスト
- トップダウンテストとボトムアップテスト
- 同値分割
- 境界値分析
- デシジョンテーブル
- ペアテスト（直交表）
- 状態遷移
テスト手法の分類
（SWEBOK：Software EngineeringBody of Knowledge ソフトウェアエンジニアリング基礎知識体系）
テスト手法 -+- 静的テスト -+- 人間による検査
：ソースコードレビュー、設計書レビュー、インスペクションなど
+- コンピュータによる検査
+- 動的テスト -+- ホワイトボックステスト（構造テスト）
+- ブラックボックステスト（機能テスト）
◆テストツール（Javaの例）
静的テストツール
メトリクス計測：ソースコードの複雑度（注2）やクラス間の結合度を計測するツール。計測値を基に、ソースコードの修正・テスト重点化部分の決定などを行う
MetrixPlugin for Eclipse
Eclipse Metrics
JMetric
JDepend
コード解析
PMD
FindBugs
JCSC
Checkstyle
Jlint
Hammurapi
動的テストツール
カバレッジ計測
JCoverage(dj Unit)
Clover
Coverlipse
EMMA
JCover
Jester
テストケース作成支援
JTestCase
Struts TestCase
EasyMock
jMock
dbMonster
TestGen4J
負荷（性能）試験ツール
Eclipse TPTP
JMeter
OpenSTA
JCrawler
Dieseltest
The Grinder
プロファイルツール：クラスやオブジェクトごとの実行時間やメモリ使用量、実行順序などを監視するツール。性能上のボトルネックやメモリリークを発見するために利用できる
Eclipse TPTP
NetBeans Profiler
jconsole(Java5付属)
FProfiler
テスト実行ツール
JUnit、Cactus、HttpUnit
djUnit、Eclipse TPTP、Selenium
jfcUnit、Abbot、Jamelon
その他
BTSツール：バグ管理システム（Bug Tracking System）
Bugzilla
scarab
Trac
http://www.thinkit.co.jp/cert/marugoto/3/4/1/2.htm
◆TDD
TDDは品質を向上させるが、時間もかかる（pdf）：「研究チームが明らかにしたのは、TDDを行うチームはTDDを行わないチームに比べ、欠陥密度にして60から90%優れているということでした。また、プロジェクトを完了させるのに15から35%多く時間がかかっていたことも分かりました。」
ソフトウェア品質の神話に関する実証的研究
http://www.infoq.com/jp/news/2009/10/exploding-myths
◆ソフトウェアメトリクス
代表的な測定対象：
LOC（Line of Code） コード行数
LCOM（Lack Of Cohesion Of Methods） メソッドの凝集度の欠落
Complexity 複雑度
Couplings 結合度
結合度：あるクラスが別のクラスに依存している度合い
結合度が高くなると複数のクラスやパッケージ間で依存度が上がってしまうため、保守やメンテナンス、仕様変更などの対応がしづらくなります。また、設計的な観点からしても、複雑で分かりづらいものになってしまいます。
結合度の測定方法：クラスの中に定義されている型の種類の数を数える。具体的には、継承クラス、インターフェイス、メンバ属性、メソッドのパラメータなど。
型の数が多いとほかのクラスやパッケージ間の依存関係が分散し過ぎていると判断できる。
凝集度：クラスやパッケージ内の機能要素と情報要素間の関連性の強さを表す指標
互いに関連する機能や情報があちこちに分散していると、仕様変更が生じた場合の影響範囲が広くなってしまいます。これらの機能や情報が局所化されている、つまりは閉じたモジュール内に収まっていることが望ましいわけです。そのため、基本的には凝集度は高いほど良い設計といえます。
凝集度の測定方法：メンバ変数1つ当たりへアクセスするメソッドの数が少ないとLCOM*は1へ近づき、多ければLCOM*は0へ近づきます。つまり、LCOM*の値が小さいほど凝集度が高いといえます。
凝集度と結合度は具体的にはどういうものなのかという話
http://d.hatena.ne.jp/chung-zee/20091104/p1
Eclipse Metrics Plugin（Frank Sauer）
http://www.atmarkit.co.jp/fjava/rensai3/eclipsetst03/eclipsetst03_2.html
◆参考
品質とは
http://homepage3.nifty.com/kaku-chan/q_and_p/what_quality.html
ThinkIT 品質管理
http://www.thinkit.co.jp/cert/project/1/5/2.htm
ソフトウェア品質特性
http://sw-quality.com/swcharast.aspx
いまさら聞けない 形式手法入門
http://monoist.atmarkit.co.jp/fembedded/special/fm/fm01.html
「プログラムの正しさ」に関する研究から生まれた、品質向上のための手法（ツール）
誰でも使える形式手法（1）
http://monoist.atmarkit.co.jp/fembedded/articles/formalmethod/01/formalmethod01a.html
初めてのソフトウェアメトリクス
http://www.atmarkit.co.jp/farc/rensai/matrix01/matrix01.html
http://gihyo.jp/news/interview/20090714
テスト工程だけでなく開発プロジェクトのライフサイクル全体でテストを考える，すなわち品質向上に対する意識を高める必要がある，ということです
日産自動車におけるソフトウェア品質向上活動
http://www.jasst.jp/archives/jasst06e/pdf/B3-1.pdf
Visual Studio 2005を活用した、テスト駆動開発とソフトウェア品質向上アプローチ
http://www.thinkit.co.jp/free/project/13/1/
チーム開発ここまできた、個人からチームの生産性向上へ
http://www.thinkit.co.jp/free/project/17/1/
ソフトウェア品質改善のすすめ
http://www.ashisuto.co.jp/service/consul/column/1184256_3224.html
基本設計におけるレビューの勘どころ
http://itpro.nikkeibp.co.jp/article/COLUMN/20060809/245521/?ST=upper&P=2
根性論では改善しない組み込みソフトの品質
http://monoist.atmarkit.co.jp/fembedded/special/scm/scm_a.html
