SlideShare una empresa de Scribd logo
1 de 40
Descargar para leer sin conexión
TS-1
1
メトリクスによるソフトウェア品質
評価・改善および製品品質実態
鷲崎 弘宜
早稲田大学グローバルソフトウェアエンジニアリング研究所長・教授
国立情報学研究所 客員教授
株式会社システム情報 取締役(監査等委員)
株式会社エクスモーション 社外取締役
TS-1TS-1
目次
• ソフトウェアの品質とメトリクス
• ゴール指向の測定 GQMとGQM+Strategies
• GQMに基づく組込みソフトウェア品質改善事例
• 国際規格と品質ベンチマーク
2 2
TS-1TS-1
品質とは
• 品質: あるものの特性または属性 [American
Heritage Dictionary]
• ソフトウェア品質: ソフトウェアの使用時に必要性
を満たす能力を決定する属性全体 [ISO9126-
1][ISO25000][JIS0129-1]
– 属性: ソフトウェアの定性的/定量的に測定可能な特徴
• 品質モデル ISO/IEC 25010:2011 SQuaRE
– 利用時の品質: 有効性、効率性、リスク回避性、満足
性、利用状況網羅性
– 製品品質(内部・外部品質): 機能適合性、互換性、セ
キュリティ、信頼性、使用性、性能効率性、保守性、移
植性
3 3
TS-1TS-1
メトリクス(Metric / Metrics)
• 測定の方法と尺度
– 方法: 属性(測定可能な特徴)の尺度上の値や分類への対応
付け
– 尺度: 値や分類の集合
– 対象: プロダクト、プロセス、リソース
• 測定できない事柄は、管理できない(T. DeMarco)
– ソフトウェア工学 = ソフトウェアの開発、運用、および保守に
対する系統的で規律に基づいた定量的アプローチ
[SWEBOK]
– Prj成功率 31% → 定量的評価導入Prj 46% [矢口08]
……
……
……
測定方法測定方法
測定尺度
測定プロセス
メトリクス
測定結果
(値、分類)
4
[SWEBOK] 松本吉弘 監訳: ソフトウェアエンジニアリング基礎知識体系―SWEBOK2004, オーム社, 2005.
[矢口08] 矢口竜太郎, 吉田洋平: 成功率は31.1%, 日経コンピュータ12月1日号, 2008.
4
TS-1TS-1
測定方法
• ソフトウェアの抽象的な特定側面を捉える
• 測定方法が異なれば測定結果も変わる
• 定義方法: テキスト、図、数式
1:/* strncat()は、文字列srcからcount数の文字を文字列destに付加し、さ
2:らに終端にnull文字を付加する。重なるオブジェクト間でコピーしようとする
3:場合、動作は未定義である。*/
4:char *strncat(char *dest, const char *src, size_t count)
5:{
6: char *temp=dest;
7: if (count) {
8: while (*dest)
9: dest++;
10: while ((*dest++=*src++)) {
11: if (--count ==0) {
12: *dest=‘¥0’; break;
13: }
14: }
15: } return temp;
16:}
5 5
TS-1TS-1
メトリクスの使いどころ
• 現在
– 把握、評価
– ヒストグラム、管理図ほか
• 未来
– 予測、計画
– 散布図、回帰分析ほか
要求
定義
設計 実装 テスト
機能
仕様書
ファンクション
ポイント
モジュール
設計
凝集度
結合度
ソース
コード
複雑度
コード行数
欠陥票
欠陥密度
テスト
ケース
消化数
工数、期間
件
数
測定値
例: サイクロマティック複雑度
被使用外部ファイル率
関数
再利
用率
鷲崎弘宜,田邉浩之,小池利和,ソースコード解析による品質評価の仕組み,日経エレクトロニクス 2010/1/25
鷲崎弘宜, 小池利和, 波木理恵子, 田邉浩之, "C言語プログラムソースコードの再利用性測定法とその評価", ソフトウェアテストシンポジウム JaSST'09
6
TS-1TS-1
主なメトリクス
名称 定義 用途
コード行数(LOC) コードの行数 規模の把握、他のメトリ
クスの正規化
ファンクションポイン
ト(FP)
機能量 規模の見積もり
サイクロマティック複
雑度(CC)
制御フローグラフの経路
数
複雑さの把握
凝集度 モジュール内の要素のま
とまり
複雑さの把握
結合度 モジュール間の結合関係
の多さ
複雑さの把握
欠陥密度(DD) 欠陥数 / 新規・変更LOC 品質の把握、開発プロセ
ス全体の有効性把握
欠陥除去率(DRE) 欠陥摘出数 / 当該時点
欠陥数
開発プロセス全体や工
程の有効性把握
消化済みテストケー
ス数
当該時点までの消化済
みテストケース数
テストの進捗把握
プロダクト
プロセス
7 7
TS-1TS-1
目次
• ソフトウェアの品質とメトリクス
• ゴール指向の測定 GQMとGQM+Strategies
• GQMに基づく組込みソフトウェア品質改善事例
• 国際規格と品質ベンチマーク
8 8
落とし穴「ホーソン効果」
9nicolasdsampson.com, Observe And Learn: The Magic Of Paying Attention
http://nicolasdsampson.com/wp-content/uploads/2012/10/2010_12_06_observe-learn-magic-paying-attention.jpg
TS-1TS-1
コツ: Goal-Question-Metric (GQM)
• 明確に目標を据えて、目標に対して必要なメトリクスを対応
付けるゴール指向(目標指向)な枠組み
• 目標(Goal): 測定上の目標
• 質問(Question): 目標の達成を評価するための質問
• メトリクス(Metric): 質問に回答するために必要な定量的デ
ータを得るための主観的・客観的メトリクス
測定する事柄
の決定
測定結果の
解釈
M. メトリクス
G. 目標
Q. 質問
収集データ
目標達成評価
答え
測定値
R. van Solingen, E. Berghout, “The Goal/Question/Metric Method” McGraw-Hill Education, 1999; ISBN 0-07709-553-7.
10 10
TS-1TS-1
GQMモデル(グラフ)の例
• 目標
– G. コードクローン含有の観点から保守性の低いコードを
特定できている。
• 質問
– Q1: コードクローンは存在するか? → M1, M2
– Q2: 発見されたコードクローンは保守上有害か? → M3
• メトリクス
– M1: ソースコードの全体的な重複度
– M2: モジュール単位のコードクローン含有率
– M3: コードクローンに対するマネージャの主観的評価
11
G
Q1 Q2
M1 M2 M3
楠本真二, 肥後芳樹, “GQMパラダイムを用いたソフトウェアメトリクスの活用”, コンピュータソフトウェア, 2012.
V. Basili, et al.: Goal, Question, Metric Paradigm, Encycloperia of Software Engineering, Vol. 1(1994)
リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの", 日経BP社 , 2009.
11
TS-1TS-1
目標テンプレートとコンテキスト
• 目標の一般性、扱う範囲の明確化
• テンプレート
– 例: コードクローン含有の観点から保守性の低いコードを
特定できている。
– 対象 (Analyze) 例: ソースコード
– 目的 (Purpose) 例: 保守性の低いコードの特定
– 関心 (Respect to) 例: コードクローン情報
– 視点 (View) 例: プロジェクトマネージャ
– 環境 (Context) 例: A社の開発環境
• 環境
– ドメイン、開発者数、経験、開発プロセス・手法、規模・工
数、信頼性要求、・・・
12
楠本真二, 肥後芳樹, “GQMパラダイムを用いたソフトウェアメトリクスの活用”, コンピュータソフトウェア, 2012.
V. Basili, et al.: Goal, Question, Metric Paradigm, Encycloperia of Software Engineering, Vol. 1(1994)
リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの", 日経BP社 , 2009.
12
TS-1TS-1
質問導出の観点
• 測定対象そのものを目的から見て明確にする
– 例: ○○はいくらか?
• 対象の属性を評価者の視点から見て明確にす
る
– 例: ○○は(従来と比べて)改善されているか?
• 対象の特徴を評価者の視点から見て評価する
– 例: ○○は××からみて目に見えて改善されている
か?
13
楠本真二, 肥後芳樹, “GQMパラダイムを用いたソフトウェアメトリクスの活用”, コンピュータソフトウェア, 2012.
13
TS-1TS-1
仮定と解釈
• 仮定(Hypothesis, Assumption)
– Question導出にあたり仮定している事柄
– 例 A. 要求が不安定であれば設計は頻繁に変更される。
– 測定評価の繰り返しにおける見直し
• 解釈(Interpretation)
– もし「条件式」ならば「Goalは達成・未達成である」
– 例 I. もしLOCが少なすぎず、かつ、設計変更回数が一
定以上ならば、要求が不安定な可能性がある。
– 多面的な捉え方
– 閾値の明確化: ベンチマーク分布、経験ベース、欠陥と
の照らし合わせなど [Alves10]、最初は大まかに&デー
タ蓄積と現物確認を経て精密に
リンダ・M・ライルドほか著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの基礎 ソフトウエアの測定と見積もりの正しい作法", 日経BP社 , 2009.
Monden, Basili, et al.: Customizing GQM Models for Software Project Monitoring, IEICE Trans., 2012.
Tiago L. Alves, et al., “Deriving Metric Thresholds from Benchmark Data,” ICSM 2010
14
TS-1TS-1
GQMの拡張: 仮定と解釈
15
Monden, Basili, et al.: Customizing GQM Models for Software Project Monitoring, IEICE Trans., 2012.
G. 特定プロジェクトにおける要求の不安定さを把握できている
Q. ソースファイルの
変更頻度はいくらか?
Q. ファイルの変更
規模はいくらか?
FCt. 一週間以内の
ファイル更新回数
FCd. 一週間以内の削除
を伴うファイル更新回数
FLa. 一週間以
内の追加行数
A. 要求が不安定であれば
コードは頻繁に削除を
伴って変更される
A. 要求が不安定であれば
コードは大きく変更される
FLd. 一週間以
内の削除行数
I. FCt が極端に大きくなく、かつ、
FCdが以前よりも大きいのであれ
ば、要求が不安定な可能性あり
I. FLa が極端に大きくなく、かつ、
FLdが以前よりも大きいのであれ
ば、要求が不安定な可能性あり
・・・
15
TS-1TS-1
落とし穴「有効な組織アクションに繋がっていない」
16
製品の信頼性や使いやす
さを改善して、顧客満足度
を10%上げるぞ!
経営層
テスト効率を上げます。
保守性も改善させます。
開発部
不具合数、さらには、プログラ
ムの複雑度を測定します。
品質保証部
16
TS-1TS-1
コツ「縦に、アクションに繋げる」 GQM+Strategies
17
顧客満足度10%向上
製品の信頼性
を改善する
製品の使いや
すさを改善する
不具合指摘を
20%削減
テスト効率
を改善する
保守性を
改善する
顧客満足度調査
不具合データ
プログラムの複雑さ
OG. 上位
組織目標
S. 戦略
S. 戦略
OG. 下位
組織目標
M. メトリクス
参考: Jens Heidrich, Adam Trendowicz, “測定を基にした、ソフトウェア戦略とビジネス目標の整合” IPA/SEC資料
M. メトリクス
17
TS-1TS-1
測定プログラム運用プロセス
18
6 パッケージ化と改善
目標と戦略を適合し改善
背景と仮定の是正
学習の記録
0 初期化
コミットメント
人材 & 責任
5 結果の分析
・データを分析し、戦略を改定
・結果のレビューと伝達
・コスト/メリットの分析
1 特性化(Characterize)
・適用範囲の定義
・環境/事実の特性化
2 目標設定
・組織構造を特定(determine)
・ギャップ分析の実施
※現状の施策、データ等の確認
・目標の優先順位づけ
・グリッド導出(derivation)プロセスの実施
3 プロセスの選択
・戦略実施の計画
・データ収集と分析の仕方の整理
・フィードバックの仕組みの定義
4 モデルの実行
・戦略の適用
・データの収集と検証
・フィードバックセッションの実施
Jens Heidrich, Adam Trendowicz, IPA訳, 測定を基にしたソフトウェア戦略とビジネス目標の整合, 2012
18
落とし穴「未来が今の延長とは限らない」
19
TS-1TS-1
コツ「データと機械学習による改善(PDCA)」
20
10 25
300
150
M. 関数の数
M.実行行数
OK
NG
71
M. 関数の数
M.実行行数
OK
NG
△ OK, ○ NG
N. Tsuda, H. Washizaki, et al., Machine Learning to Evaluate Evolvability Defects: Code Metrics Thresholds for a Given Context, QRS2018
コマツとの共同研究
20
TS-1TS-1
目次
• ソフトウェアの品質とメトリクス
• ゴール指向の測定 GQMとGQM+Strategies
• GQMに基づく組込みソフトウェア品質改善事例
• 国際規格と品質ベンチマーク
21 21
TS-1TS-1
コツ「横に広げて多面的に見る」
22
鷲崎弘宜,田邉浩之,小池利和,ソースコード解析による品質評価の仕組み,日経エレクトロニクス 2010/1/25
[Adqua] http://www.ogis-ri.co.jp/product/b-08-000001A6.html
保守性
モジュール性 再利用性 修正性 ・・・
コールグラフ
階層の深さ
サイクロマテ
ィック複雑度
関数内の
戻り点の数
処理が複雑
すぎないか?
処理が構造化
されているか?
…… …
…… …
…… …
…… …
・・・
・・・ ・・・
G. 目標
対象
M. メトリクス
Q. 質問
22
TS-1TS-1
対象例: ETロボコン・コード改善
• 規模: 1481 ELOC, 18クラス, 121関数
• サイクロマティック複雑度の大きい関数をリストアップ
• しかし「数」だけでは問題は分からない → 対象の詳細調査へ
23
保守性
得点 78.6
偏差値 36.1
解析性
得点 79.3
偏差値 38.7
変更性
得点 89.3
偏差値 46.2
安定性
得点 84.3
偏差値 50.0
試験性
得点 61.5
偏差値 35.8
品質特性
品質副特性
ファイル名 関数名
サイクロマ
ティック複雑度
関数の
物理行数
Magi.cpp decideSynthetic() 12 55
Tactics.cpp getDriver(DriveStatus::eDifficultKind) 12 51
StepDriver.cpp drive(bool) 11 119
SeesawDriver.cpp drive(bool) 8 100
GarageDriver.cpp driveIn(void) 8 73
Main.cpp TASK(TaskDrive) 7 91
Magi.cpp getDriveStatus() 7 37
PositionDecision.cpp updateLocation() 6 81
Tactics.cpp ~Tactics(void) 5 15
ファイル名 関数名
サイクロマ
ティック複雑度
関数の
物理行数
Magi.cpp decideSynthetic() 12 55
Tactics.cpp getDriver(DriveStatus::eDifficultKind) 12 51
StepDriver.cpp drive(bool) 11 119
SeesawDriver.cpp drive(bool) 8 100
GarageDriver.cpp driveIn(void) 8 73
Main.cpp TASK(TaskDrive) 7 91
Magi.cpp getDriveStatus() 7 37
PositionDecision.cpp updateLocation() 6 81
Tactics.cpp ~Tactics(void) 5 15
Question 得点 偏差値 メトリック 得点
処理が複雑すぎないか 44.5 37.7
制御フローグラフの最大ネスト数 40.9
サイクロマティック複雑度 46.8
処理が構造化されているか 99.5 46.5 break等のないswitch文の数 91.0
要素間の結合度は低くなって
いるか
75.9 48.1
使用する他クラスの種類数 69.3
自クラスを使用する他クラスの種類数 70.4
要素の規模は適切か 59.1 43.7
関数の実行コード行数 34.5
クラスの実行コード行数 35.6
ファイル内の関数の数 85.6
クラス内のメソッド数 78.1
鷲崎, 阿佐美, 田邉, ETロボコンの事例で学ぶモデル活用の効能:
第2回参加チームの事例,日経エレクトロニクス, 2011年9月5日
TS-1TS-1
//=============================================================================
// 走行ステータスに応じて走行クラスを返却
Driver* Tactics::getDriver(DriveStatus::eDifficultKind kind)
{
Driver* drive;
drive = 0;
switch(kind)
{
case DriveStatus::LINETRACE:
if(mLineTraceDriver == 0)
{
mLineTraceDriver = new LineTraceDriver(mMaimai, mPid);
}
drive = mLineTraceDriver;
break;
case DriveStatus::SEESAW:
if(mSeesawDriver == 0)
{
mSeesawDriver = new SeesawDriver(mrGyro, mMaimai, mPid);
}
drive = mSeesawDriver;
break;
case DriveStatus::STEPS:
if(mStepDriver == 0)
{
mStepDriver = new StepDriver(mrGyro, mMaimai, mPid);
}
drive = mStepDriver;
break;
case DriveStatus::OUTCOURSE_GARAGE:
if(mGarageDriver == 0)
{
mGarageDriver = new GarageDriver(mPositionDecision);
}
drive = mGarageDriver;
break;
case DriveStatus::INCOURSE_GARAGE:
if(mGarageDriver == 0)
{
mGarageDriver = new GarageDriver(mPositionDecision);
}
drive = mGarageDriver;
break;
default:
if(mLineTraceDriver == 0)
{
mLineTraceDriver = new LineTraceDriver(mMaimai, mPid);
}
drive = mLineTraceDriver;
break;
}
return drive;
}
//=============================================================================
// 走行ステータスに応じて走行クラスを返却
Driver* Tactics::getDriver(DriveStatus::eDifficultKind kind)
{
Driver* drive;
drive = 0;
switch(kind)
{
case DriveStatus::LINETRACE:
if(mLineTraceDriver == 0)
{
mLineTraceDriver = new LineTraceDriver(mMaimai, mPid);
}
drive = mLineTraceDriver;
break;
case DriveStatus::SEESAW:
if(mSeesawDriver == 0)
{
mSeesawDriver = new SeesawDriver(mrGyro, mMaimai, mPid);
}
drive = mSeesawDriver;
break;
case DriveStatus::STEPS:
if(mStepDriver == 0)
{
mStepDriver = new StepDriver(mrGyro, mMaimai, mPid);
}
drive = mStepDriver;
break;
case DriveStatus::OUTCOURSE_GARAGE:
if(mGarageDriver == 0)
{
mGarageDriver = new GarageDriver(mPositionDecision);
}
drive = mGarageDriver;
break;
case DriveStatus::INCOURSE_GARAGE:
if(mGarageDriver == 0)
{
mGarageDriver = new GarageDriver(mPositionDecision);
}
drive = mGarageDriver;
break;
default:
if(mLineTraceDriver == 0)
{
mLineTraceDriver = new LineTraceDriver(mMaimai, mPid);
}
drive = mLineTraceDriver;
break;
}
return drive;
}
//=============================================================================
// 難所走行状態の更新
void Magi::decideSynthetic()
{
// 次に目指す難所を取得
ChangePoint p = mStrategy.getChangePoint();
// 事前に登録した判定クラスから難所を取得
int decideCount = 0;
for (SINT i = 0; i < mNumOfJudge; i++) {
if (mJudgeAddressTable[i]->decideHard(p)) {
decideCount++;
}
}
if (decideCount >= 1) {
switch (p.getPointKind()) {
case ChangePoint::SEESAW_IN:
mDifficultKindBuf = DriveStatus::SEESAW;
mCangeCount = 0;
break;
case ChangePoint::SEESAW_OUT:
mDifficultKindBuf = DriveStatus::LINETRACE;
mCangeCount = 0;
break;
case ChangePoint::STEPS_IN:
mDifficultKindBuf = DriveStatus::STEPS;
mCangeCount = 0;
break;
case ChangePoint::STEPS_OUT:
mDifficultKindBuf = DriveStatus::LINETRACE;
mCangeCount = 0;
break;
case ChangePoint::OUTCOURSE_GARAGE:
mDifficultKindBuf = DriveStatus::OUTCOURSE_GARAGE;
mCangeCount = 0;
break;
case ChangePoint::INCOURSE_GARAGE:
mDifficultKindBuf = DriveStatus::INCOURSE_GARAGE;
mCangeCount = 0;
break;
default:
break;
}
// 目指す難所を更新する
mStrategy.next();
}
// 難所判定後、時間差で走行を切替えるケースに備える
if (mCangeCount > 0) {
mCangeCount--;
} else if (mCangeCount == 0) {
mCangeCount--;
// 走行切替
mStatus.setDifficultKind(mDifficultKindBuf);
}
}
//=============================================================================
// 難所走行状態の更新
void Magi::decideSynthetic()
{
// 次に目指す難所を取得
ChangePoint p = mStrategy.getChangePoint();
// 事前に登録した判定クラスから難所を取得
int decideCount = 0;
for (SINT i = 0; i < mNumOfJudge; i++) {
if (mJudgeAddressTable[i]->decideHard(p)) {
decideCount++;
}
}
if (decideCount >= 1) {
switch (p.getPointKind()) {
case ChangePoint::SEESAW_IN:
mDifficultKindBuf = DriveStatus::SEESAW;
mCangeCount = 0;
break;
case ChangePoint::SEESAW_OUT:
mDifficultKindBuf = DriveStatus::LINETRACE;
mCangeCount = 0;
break;
case ChangePoint::STEPS_IN:
mDifficultKindBuf = DriveStatus::STEPS;
mCangeCount = 0;
break;
case ChangePoint::STEPS_OUT:
mDifficultKindBuf = DriveStatus::LINETRACE;
mCangeCount = 0;
break;
case ChangePoint::OUTCOURSE_GARAGE:
mDifficultKindBuf = DriveStatus::OUTCOURSE_GARAGE;
mCangeCount = 0;
break;
case ChangePoint::INCOURSE_GARAGE:
mDifficultKindBuf = DriveStatus::INCOURSE_GARAGE;
mCangeCount = 0;
break;
default:
break;
}
// 目指す難所を更新する
mStrategy.next();
}
// 難所判定後、時間差で走行を切替えるケースに備える
if (mCangeCount > 0) {
mCangeCount--;
} else if (mCangeCount == 0) {
mCangeCount--;
// 走行切替
mStatus.setDifficultKind(mDifficultKindBuf);
}
}
24
鷲崎, 阿佐美, 田邉, ETロボコンの事例で学ぶモデル活用の効能: 第2回参加チームの事例,日経エレクトロニクス, 2011年9月5日
TS-1TS-1
「数」から問題・原因の特定へ
• 散らばり or もつれあい
• 「難所に関する処理・責務(関心事)」のパッケージ横断な散らばり
25
コンポーネント
ECROBOT API
走行系
判定処理系
3重多数決
+ 走行ステータス更新() : 走行ステータス
+ 開始判定() : boolean
+ 総合判定() : void
戦略
+ 目標切替ポイント取得() : 切替ポイント
切替ポイント
- 灰色検知フラグ
- 座標
- 推定時間
審判
+ 難所判定(切替ポイント) : boolean
+ フェイルセーフ判定(走行ステータス) : boolean
時間判定
- 現在時間
+ 時間判定(推定時間) : void
- 時間更新() : void
位置判定
- 現在位置
+ ロケーション判定(座標) : void
- 現在位置更新() : void
色判定
- 現在色
+ 灰色検知(灰色検知フラグ) : void
- 現在色更新() : void
Main
+ 初期化() : void
+ 走行開始() : void
走行ステータス
- IN/OUTフラグ
+ getter() : void
+ setter() : void
<<enum>>
走行種別
- キャリブレーション
- 走行
- 停止
<<enum>>
難所種別
- ライントレース
- 階段
- シーソー通過
- ガレージイン
戦術
- 走行
+ 走行クラス取得(走行ステータス) : 走行
走行
+ 走る() : void
ライントレース走行
階段走行
シーソー通過走行
ガレージイン走行
ロケーション
+ 現在座標取得() : void
まいまい式
- 補正ライトセンサ値
- 定周期ライトON() : void
- 定周期ライトOFF() : void
+ 補正ライトセンサ値取得() : void
PID制御
- PID算出() : void
+ 進行方向取得() : 進行方向
インテリジェントモーター
- 補正係数
+ モーター出力補正() : void
+ モーター出力設定(右出力, 左出力) : void
タッチセンサ
+ センサ値取得() : boolean
タイマー
+ 時間取得() : 時間
ジャイロセンサ
+ センサ値取得() : ジャイロセンサ値
ライトセンサ
+ センサ値取得() : ライトセンサ値
+ ランプ設定(ON/OFF) : void
モーター
+ モーター出力設定(出力) : void
+ 回転数取得() : 回転数
1
走行クラスを
取得する
1
切替ポイントを
取得する
*
1
3
難所を判定する
1
走行ステータスを取得する
1
走る
4
生成する
1
センサ値を
取得する
1
1
時間を取得
する
1
1
現在座標を
取得する
1
1
センサ値を
取得する
1
1
ライトセンサ値を
取得する
1
1
センサ値を
取得する
1
1
モーター値を設定する
2
1
モーター値を
設定する
1
1
進行方向を
取得する
1
1
ライトセンサ値を
取得する
1
1
回転数を取得する
2
鷲崎, 阿佐美, 田邉, ETロボコンの事例で学ぶモデル活用の効能: 第2回参加チームの事例,日経エレクトロニクス, 2011年9月5日
TS-1TS-1
改善結果
26
走行系判定処理系
3重多数決
+ 難所判定(切替ポイント) : boolean
切替ポイント
- 灰色検知フラグ
- 座標
- 推定時間
審判
+ 難所判定(切替ポイント) : boolean
+ フェイルセーフ判定(走行ステータス) : boolean
時間判定
- 現在時間
+ 時間判定(推定時間) : void
- 時間更新() : void
位置判定
- 現在位置
+ ロケーション判定(座標) : void
- 現在位置更新() : void
色判定
- 現在色
+ 灰色検知(灰色検知フラグ) : void
- 現在色更新() : void
Main
+ 初期化() : void
+ 走行開始() : void
走行ステータス
- IN/OUTフラグ
+ getter() : void
+ setter() : void
<<enum>>
走行種別
- キャリブレーション
- 走行
- 停止
戦術
- 走行
+ 走行開始() : void
走行
+ 走る() : void
+ 切替ポイント取得(IN/OUT) : 切替ポイント
ライントレ ース走行
階段走行
シーソー通過走行
ガレ ージイン走行
1 1
3
難所を判定する
1
1
難所を判定する
1
1 1
+構成要素1..* {ordered}
1
+出時0..1
1
+入時0..1
1
1
走行を開始する
1
Question 得点 偏差値 メトリック 得点
処理が複雑すぎないか 52.0 42.7
制御フローグラフの最大ネスト数 48.0
サイクロマティック複雑度 55.2
処理が構造化されているか 98.7 46.1 break等のないswitch文の数 90.8
要素間の結合度は低くなって
いるか
75.6 47.9
使用する他クラスの種類数 68.8
自クラスを使用する他クラスの種類数 67.7
要素の規模は適切か 62.7 47.4
関数の実行コード行数 37.6
クラスの実行コード行数 39.6
ファイル内の関数の数 87.6
クラス内のメソッド数 81.1
7.5
UP
3.6
UP
7.1
UP
8.4
UP
3.1
UP
• 関心事の局
所化
• 保守性改善
鷲崎, 阿佐美, 田邉, ETロボコンの事例で学ぶモデル活用の効能: 第2回参加チームの事例,日経エレクトロニクス, 2011年9月5日
TS-1TS-1
目次
• ソフトウェアの品質とメトリクス
• ゴール指向の測定 GQMとGQM+Strategies
• GQMに基づく組込みソフトウェア品質改善事例
• 国際規格と品質ベンチマーク
27 27
落とし穴「オレオレ品質」
28
画像: @VS_oresagi https://twitter.com/vs_oresagi
TS-1TS-1
コツ「関係をつかむ」
29
コードの規模・
複雑さメトリクス
開発主体
変更回数
変更規模
欠陥
M. ファイル規模
M. 他ファイルとの呼び出し関係
・・・
S. Sato, et al., Effects of Organizational Changes on Product Metrics and Defects, APSEC'13
富士通コネクテッドとの共同研究
29
TS-1TS-1
コツ「国際規格の活用」
30
ISO/IEC 25023
内部・外部品質測定
ISO/IEC 25023
内部・外部品質測定
利用時の
品質
利用時の
品質
外部品質外部品質内部品質内部品質
ソフトウェア システム 業務
……
……
……
……
……
……
どのように
影響?
ISO/IEC 25022
利用時の品質測定
ISO/IEC 25022
利用時の品質測定
ISO/IEC 25051 既製ソフト品質要求ISO/IEC 25051 既製ソフト品質要求
ISO/IEC 25010 品質モデルISO/IEC 25010 品質モデル
現実の入力から
どのように
測定評価
すればよいか?
• PSQ認証
– コンピュータソフトウェア協会(CSAJ)
– カタログ、マニュアル、仕様書、試験文書
– 全品質特性
30
TS-1TS-1
IPA RISE委託研究: 測定評価と分析によるソフトウェア製
品品質の実態定量化および総合的品質評価枠組みの確立
31
• 21製品個別評価と業界実態分析
• 国際標準ベンチマークへ Waseda
Software Quality Benchmark (WSQB2017)
http://www.washi.cs.waseda.ac.jp/wsqb/
SEC journal, Vol. 14, No. 1, 2018
• 国際規格 ISO/IEC 25000
SQuaRE シリーズを具体化
• 製品品質、利用時品質の網羅
と関係分析
0
20
40
60
80
100
機能適合性
性能効率性
互換性
使用性
信頼性
セキュリティ
保守性
移植性
0
5
10
1 2 3 4 5 6
12ベンダ
21製品
4評価機関
一部委託
一部結果
ISO/IEC JTC1/SC7/WG6
SQuaREエディタ
協力
評価結果
TS-1TS-1
品質測定評価の枠組み
32
Q1. 社内サーバのみ使用する経路は?
Q2. 社外サーバも使用する経路は?
Q3. クライアント間直接通信(P2P等)は?
Q4. 申請者管理サーバ使用の経路は?
G.情報アクセスや情報伝達などの
行為とその内容が偽って否認され
ないようにシステムができている
M. 署名経路率 = 署名経路数
/ 各種別の経路数
例: 否認防止性
研究チーム 製品提供元
1 GQM法でSQuaREメ
トリクス具体化
2 測定ツール化(様
式、コード解析、アン
ケート・テスト)
3 コード解析実施、
ユーザテスト実施
様式記入、ア
ンケート回収
4 測定値・スコア計算、
診断、集計
パーセンタイルによるスコア化
例: 全体のうち70%の製品群よりも上 = 0.7
対応言語
認証方式
配備形態
不具合情報
試験情報
機能情報※
DB情報※
NW情報※
コード※
運用情報※
(※任意) 高低
件
数
測定値
TS-1TS-1
33
機能適合性 性能効率性 互換性 使用性
信頼性 セキュリティ 保守性 移植性
有効性 効率性 満足性 リスク回避性
利用状況網羅性 • 信頼性: 全体的に同程度
• 使用性、保守性: 低いほうにやや集中
• 互換性: 2極化、データ交換を一部考慮せず
• セキュリティ: 2極化、暗号化や破損防止に差あり
• 有効性、効率性: 2極化、タスク実行に一部難あり
TS-1TS-1
品質特性間の関係分析
34
製品品質 利用時の品質
p値<0.1p値<0.1
性能効率性 互換性 使用性 信頼性 セキュリティ 保守性 移植性 有効性 効率性 満足性 リスク回避性 利用状況網羅性
機能適合性 0. 31 0. 19 -0. 72 0. 37 -0. 05 0. 50 0. 31 -0. 14 0. 52 1. 00 1. 00 1. 00
性能効率性 0. 44 0. 24 0. 36 -0. 17 0. 37 0. 32 0. 32 -0. 10 -0. 50 -0. 50 -0. 50
互換性 0. 04 0. 17 -0. 06 0. 36 -0. 04 -0. 14 0. 05 -0. 50 -0. 50 -0. 50
使用性 0. 17 -0. 21 0. 11 0. 44 -0. 09 -0. 20 -1. 00 -1. 00 -1. 00
信頼性 0. 30 0. 41 0. 45 -0. 08 0. 11 1. 00 1. 00 1. 00
セキュリティ -0. 06 0. 19 0. 64 -0. 34 0. 50 0. 50 0. 50
保守性 0. 26 -0. 29 0. 01 1. 00 1. 00 1. 00
移植性 -0. 21 0. 67 0. 50 0. 50 0. 50
有効性 0. 03 -1. 00 -1. 00 -1. 00
効率性 1. 00 1. 00 1. 00
満足性 1. 00 1. 00
リスク回避性 1. 00
• 信頼性が高いほど、保守性や移植
性も高い
– 高信頼製品ほど長期にわたる保守や
様々な環境への移植や適合が求めら
れる可能性
• 移植性が高いほど、使用性や効率
性が高い
• セキュリティが高いほど、有効性も高
い
• 機能適合性が高いほど、使用性が
低い
– 副作用、使用性軽視の可能性
• 信頼性が高いほど、保守性や移植
性も高い
– 高信頼製品ほど長期にわたる保守や
様々な環境への移植や適合が求めら
れる可能性
• 移植性が高いほど、使用性や効率
性が高い
• セキュリティが高いほど、有効性も高
い
• 機能適合性が高いほど、使用性が
低い
– 副作用、使用性軽視の可能性
TS-1TS-1
互換性性能効率性機能適合性
安定 漸増 爆発
信頼性 有効性
信頼性モデル: 発見時間と数の関係を分析し欠陥数を予測
爆発(3)漸増(3)安定(3製品)
• 機能適合性、有効性: 安定
で高品質
• 性能効率性、互換性: 爆発
において低品質
• 他の特性: 信頼性タイプで相
違無し
TS-1TS-1
コンテキスト別の分析
36
• ドメイン別: 互換性、セキュリ
ティに顕著な差
• パッケージ製品: セキュリテ
ィ強化が課題
• クラウド製品: 移植性、保守
性、信頼性の測定方法が不
適当な可能性
• 規模、期間、開発形態: 顕著
な相違無し
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
機能
適…
性能
効…
互換
性
使用
性
信頼
性
セ
キ…
保守
性
移植
性
有効
性
効率
性
満足
性
リスク
回…
利用
状…
グループ支援
(n=5)
データ集計(n=5)
会計(n=4)
セキュリティ(n=3)
数値計算シミュ
レーション(n=3)
エンドユーザ向け
サービス(n=1)
区別なし(n=21)
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
機能
適…
性能
効…
互換
性
使用
性
信頼
性
セキュ
リティ
保守
性
移植
性
有効
性
効率
性
満足
性
リスク
回…
利用
状…
パッケージ
(n=17)
クラウド(n=4)
区別なし
(n=21)
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
機能適合性
性能効率性
互換性
使用性
信頼性
セキュリティ
保守性移植性
有効性
効率性
満足性
リスク回避
性
利用状況網
羅性
0-10K(n=2)
10K-50K(n=6)
50K-100K(n=2)
100K-(n=6)
区別なし(n=16)
TS-1TS-1
37
ベンチマークによりポジショニング
確認ができ、該当製品が目指し
た強みが実現できた
小島嘉津江,森田純恵,廣瀬竹男,若本雅晶
,菊池慎司,楾晃歓,鷲崎弘宜, “ソフトウェ
ア品質技術が品質特性に与える効果の見える
化とその検証”, SEC journal, Vol. 14, No. 1, pp.
50-57, 2018.
活用: 富士通グループの事例
有効性 効率性 満足性
リスク回避
性
利用状況
網羅性
機能適合
性
性能効率
性
互換性 使用性 信頼性 セキュリティ 保守性 移植性
データ処理能力重視 ○ ○ ○ ◎ ○ ○ △ ○
早期デリバリー △ △ △ × ×
利用時の品質 システム/ソフトウェア製品品質
プロジェクト要件
要件を満たすための品質特性 (最優先:◎→○→△→×:低優先)注力する品質特性を決定
時間効率性
の試験有無
応答時間平
均
応答時間実
測対目標
ターンアラウン
ドタイム平均
ターンアラウン
ドタイム実測
対目標
スループット目
標達成率
資源効率性
の試験有無
CPU使用率
最大値
メモリ使用率
最大値
容量満足性
の試験有無
ユーザ同時ア
クセス可能数
目標達成率
大or小が望ましい 大 小 小 小 小 大 大 小 小 大 大
メトリクス測定値 1 - - - - 2.08 1 0.03 NA 1 NA
-
ログイン画面
表示
- プロセス起動 - データ蓄積 - データ保存 データ保存 - ユーザ数
- - -
データ検索
(500件)
- - - データ検索 データ検索 - -
RISEメトリクス(性能効率性)
測定条件
(サンプル)
メトリクスにより品質達成度評価
RISEベンチマークによるポジショニング評価
TS-1TS-1
まとめ、メッセージ
• ソフトウェア開発の厳しさとメトリクスの重要性
– 開発の管理、品質把握と改善
• メトリクスの限界を知り意思決定に役立てる
– 測定方法、信頼性、妥当性、負のホーソン効果
• GQMによるゴール指向の測定
– 測定と改善のプロセス
– アクションに向けて: GQM+Strategies
• 応用
– GQMを用いた組込みソフトウェア品質改善
– 品質ベンチマーク WSQF
38 38
TS-1TS-1
参考資料• メトリクス全般
– リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜
訳 , "演習で学ぶソフトウエアメトリクスの基礎 ソフトウエアの測定
と見積もりの正しい作法", 日経BP社 , 2009.
• GQM
– 鷲崎弘宜、”ゴール指向の測定評価と留意 – GQMパラダイムと
拡張 -”、メトリクス公団、Vol.1、TEF東海メトリクス勉強会、2013.
– 楠本真二、肥後芳樹: “GQMパラダイムを用いたソフトウェアメトリ
クスの活用”、コンピュータソフトウェア、29(3)、pp.29-38、2012.
• GQM+Strategies
– 早稲田大学ゴール指向経営研究会、「残念なシステム」のなくしか
た、日経ITPro、連載、2014年5月14日~6月11日
– Victor Basili, Adam Trendowicz, Martin Kowalczyk, Jens
Heidrich, Carolyn Seaman, Jürgen Münch, Dieter Rombach
著, 鷲崎弘宜, 小堀貴信, 新谷勝利, 松岡秀樹 監訳, 早稲田大学
グローバルソフトウェアエンジニアリング研究所ゴール指向経営研
究会 訳, “ゴール&ストラテジ入門: 残念なシステムの無くし方
(GQM+Strategies)”, オーム社, 2015年9月10日発行
• 事例
– 鷲崎弘宜, 田邉浩之, 小池利和, “ソースコード解析による品質評
価の仕組み”, 日経エレクトロニクス, 2010年1月25日号, 2010.
– 鷲崎弘宜, 阿左美勝, 田邉浩之, “モデル活用の効能: 第1回 モデ
ルを書く意味”~ “モデル活用の効能: 第4回 参加チームの事例
3″,日経エレクトロニクス, 日経BP社, 2011年8月8日号~11月号
39 39
TS-1
ご紹介: enPiT-Pro スマートエスイー
40
⚫ 文部科学省社会人教育事業 ‘17-’21 (代表: 鷲崎) http://smartse.jp/
⚫ 12月10日(月) スマートエスイー シンポジウム
クラウド
センサ・IoT
人工
知能
ビッグ
データ
生成
知識
抽出
革新
アプリケーション
ビジネス
価値
創造
通信・物理
情報処理
総合実践
連携校(13校)
茨城大学 群馬大学
東京学芸大学 東京工業大学
大阪大学 九州大学
工学院大学 東京工科大学
東洋大学 鶴見大学
北陸先端科学技術大学院大学
奈良先端科学技術大学院大学
情報・システム研究機構
(国立情報学研究所)
協力校(2校)
立命館大学
The BigClouT Project
教材・指導
地区展開
進学・共同
研究接続
連携企業・業界団体(23団体)
日本電気 富士通
日立製作所 東芝
いい生活 ヤフー
モバイルコンピューティング推進コンソーシアム
次世代センサ協議会
日本IT団体連盟
IT検証産業協会
コンピュータソフトウェア協会
組込みシステム技術協会
電子情報技術産業協会
全脳アーキテクチャ・イニシアティブ
新経済連盟
先端IT活用推進コンソーシアム
日本オープンオンライン教育推進協議会
デンソー ハレックス
情報医療 システム情報
題材・事例
教材・指導
受講生派遣
外部評価
想定受講者
情報系の一定知識を
持っている人
組込み・
IoTプロフェッショナル
クラウド・
ビジネスイノベー
ター
システムオブシステムズ・
品質アーキテクト
目標人材像
環境連携
BigClouT
(日欧ビックデータ・クラウド・IoT融合基盤)JMOOC
(オンライン大学講座)
オンライン全国展開
実施拠点
WASEDA NEO
(コレド日本橋内)
社会人教育プログラム
スマートエスイー SmartSE
IoT・ビッグデータ・AI × ビジネス
IoT・クラウド、ビッ
グデータ、人工知
能を活用し、高セ
キュリティかつプラ
イバシを考慮した
スマートシステム
&サービスを開発
運用し、技術領域
や分野を超え価値
創造をグローバル
にリード可能な実
践的人材の育成と
全国展開
IoT・クラウド、ビッ
グデータ、人工知
能を活用し、高セ
キュリティかつプラ
イバシを考慮した
スマートシステム
&サービスを開発
運用し、技術領域
や分野を超え価値
創造をグローバル
にリード可能な実
践的人材の育成と
全国展開

Más contenido relacionado

La actualidad más candente

アジャイル開発と品質保証の密なる関係 #quesqa
アジャイル開発と品質保証の密なる関係 #quesqaアジャイル開発と品質保証の密なる関係 #quesqa
アジャイル開発と品質保証の密なる関係 #quesqaques_staff
 
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~Hironori Washizaki
 
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOKKotaro Ogino
 
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)Yasuharu Nishi
 
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -Hironori Washizaki
 
ソフトハウスの品質保証のウソホント
ソフトハウスの品質保証のウソホントソフトハウスの品質保証のウソホント
ソフトハウスの品質保証のウソホントYasuharu Nishi
 
Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~Mineo Matsuya
 
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証Yasuharu Nishi
 
What should you shift left
What should you shift leftWhat should you shift left
What should you shift leftYasuharu Nishi
 
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacateKinji Akemine
 
アジャイル開発とメトリクス
アジャイル開発とメトリクスアジャイル開発とメトリクス
アジャイル開発とメトリクスRakuten Group, Inc.
 
Re-collection of embedded software qa in the last decade
Re-collection of embedded software qa in the last decadeRe-collection of embedded software qa in the last decade
Re-collection of embedded software qa in the last decadeYasuharu Nishi
 
アプリ開発へのOdc分析導入の取り組み
アプリ開発へのOdc分析導入の取り組みアプリ開発へのOdc分析導入の取り組み
アプリ開発へのOdc分析導入の取り組みNaokiKashiwagura
 
LINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 PresentationLINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 PresentationYasuharu Nishi
 
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドアジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドHiroyuki Ito
 
クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門H Iseri
 
社内勉強会で学んだQA2AQパターンの活用
社内勉強会で学んだQA2AQパターンの活用社内勉強会で学んだQA2AQパターンの活用
社内勉強会で学んだQA2AQパターンの活用atsushi nagata
 
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)Hironori Washizaki
 
【SQiP2016】楽天のアジャイル開発とメトリクス事例
【SQiP2016】楽天のアジャイル開発とメトリクス事例【SQiP2016】楽天のアジャイル開発とメトリクス事例
【SQiP2016】楽天のアジャイル開発とメトリクス事例Kotaro Ogino
 
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステムSEGADevTech
 

La actualidad más candente (20)

アジャイル開発と品質保証の密なる関係 #quesqa
アジャイル開発と品質保証の密なる関係 #quesqaアジャイル開発と品質保証の密なる関係 #quesqa
アジャイル開発と品質保証の密なる関係 #quesqa
 
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
 
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
 
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
 
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -
 
ソフトハウスの品質保証のウソホント
ソフトハウスの品質保証のウソホントソフトハウスの品質保証のウソホント
ソフトハウスの品質保証のウソホント
 
Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~
 
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証
 
What should you shift left
What should you shift leftWhat should you shift left
What should you shift left
 
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate
 
アジャイル開発とメトリクス
アジャイル開発とメトリクスアジャイル開発とメトリクス
アジャイル開発とメトリクス
 
Re-collection of embedded software qa in the last decade
Re-collection of embedded software qa in the last decadeRe-collection of embedded software qa in the last decade
Re-collection of embedded software qa in the last decade
 
アプリ開発へのOdc分析導入の取り組み
アプリ開発へのOdc分析導入の取り組みアプリ開発へのOdc分析導入の取り組み
アプリ開発へのOdc分析導入の取り組み
 
LINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 PresentationLINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 Presentation
 
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドアジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
 
クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門
 
社内勉強会で学んだQA2AQパターンの活用
社内勉強会で学んだQA2AQパターンの活用社内勉強会で学んだQA2AQパターンの活用
社内勉強会で学んだQA2AQパターンの活用
 
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
 
【SQiP2016】楽天のアジャイル開発とメトリクス事例
【SQiP2016】楽天のアジャイル開発とメトリクス事例【SQiP2016】楽天のアジャイル開発とメトリクス事例
【SQiP2016】楽天のアジャイル開発とメトリクス事例
 
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
 

Similar a メトリクスによるソフトウェア品質評価・改善および製品品質実態

Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Qua s tom-メトリクスによるソフトウェアの品質把握と改善Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Qua s tom-メトリクスによるソフトウェアの品質把握と改善Hironori Washizaki
 
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912Hironori Washizaki
 
ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-
ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-
ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-Hironori Washizaki
 
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎Hironori Washizaki
 
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011Yusuke Suzuki
 
テストを分類してみよう!
テストを分類してみよう!テストを分類してみよう!
テストを分類してみよう!Kenji Okumura
 
早稲田・鷲崎-ゴール指向の測定によるソフトウェア 品質評価と改善の実践的取組み (三つのコツ、三つの事例)-2015年2月19日
早稲田・鷲崎-ゴール指向の測定によるソフトウェア品質評価と改善の実践的取組み(三つのコツ、三つの事例)-2015年2月19日早稲田・鷲崎-ゴール指向の測定によるソフトウェア品質評価と改善の実践的取組み(三つのコツ、三つの事例)-2015年2月19日
早稲田・鷲崎-ゴール指向の測定によるソフトウェア 品質評価と改善の実践的取組み (三つのコツ、三つの事例)-2015年2月19日Hironori Washizaki
 
テスト 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第33回】
テスト 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第33回】テスト 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第33回】
テスト 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第33回】Tomoharu ASAMI
 
Devlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのかDevlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのかYusuke Suzuki
 
アドテク×Scala×パフォーマンスチューニング
アドテク×Scala×パフォーマンスチューニングアドテク×Scala×パフォーマンスチューニング
アドテク×Scala×パフォーマンスチューニングYosuke Mizutani
 
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423Yusuke Suzuki
 
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】 Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】 智治 長沢
 
ソフトウェア工学2023 04 開発プロセスモデル
ソフトウェア工学2023 04 開発プロセスモデルソフトウェア工学2023 04 開発プロセスモデル
ソフトウェア工学2023 04 開発プロセスモデルToru Tamaki
 
機械学習 - MNIST の次のステップ
機械学習 - MNIST の次のステップ機械学習 - MNIST の次のステップ
機械学習 - MNIST の次のステップDaiyu Hatakeyama
 
Jenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめ
Jenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめJenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめ
Jenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめatsushi_tmx
 
アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-
アジャイルテスト  -高品質を追求するアジャイルチームにおけるテストの視点-アジャイルテスト  -高品質を追求するアジャイルチームにおけるテストの視点-
アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-Satoshi Masuda
 
設計/ドメイン設計(3) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第25回】
設計/ドメイン設計(3) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第25回】設計/ドメイン設計(3) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第25回】
設計/ドメイン設計(3) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第25回】Tomoharu ASAMI
 
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か企業システムにアジャイルは必要か
企業システムにアジャイルは必要かHiromasa Oka
 
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革Hironori Washizaki
 
デブサミ関西2013【A4】コード品質は曖昧なままか(安竹由起夫氏)
デブサミ関西2013【A4】コード品質は曖昧なままか(安竹由起夫氏)デブサミ関西2013【A4】コード品質は曖昧なままか(安竹由起夫氏)
デブサミ関西2013【A4】コード品質は曖昧なままか(安竹由起夫氏)Developers Summit
 

Similar a メトリクスによるソフトウェア品質評価・改善および製品品質実態 (20)

Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Qua s tom-メトリクスによるソフトウェアの品質把握と改善Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Qua s tom-メトリクスによるソフトウェアの品質把握と改善
 
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
 
ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-
ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-
ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-
 
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎
 
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
 
テストを分類してみよう!
テストを分類してみよう!テストを分類してみよう!
テストを分類してみよう!
 
早稲田・鷲崎-ゴール指向の測定によるソフトウェア 品質評価と改善の実践的取組み (三つのコツ、三つの事例)-2015年2月19日
早稲田・鷲崎-ゴール指向の測定によるソフトウェア品質評価と改善の実践的取組み(三つのコツ、三つの事例)-2015年2月19日早稲田・鷲崎-ゴール指向の測定によるソフトウェア品質評価と改善の実践的取組み(三つのコツ、三つの事例)-2015年2月19日
早稲田・鷲崎-ゴール指向の測定によるソフトウェア 品質評価と改善の実践的取組み (三つのコツ、三つの事例)-2015年2月19日
 
テスト 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第33回】
テスト 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第33回】テスト 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第33回】
テスト 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第33回】
 
Devlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのかDevlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのか
 
アドテク×Scala×パフォーマンスチューニング
アドテク×Scala×パフォーマンスチューニングアドテク×Scala×パフォーマンスチューニング
アドテク×Scala×パフォーマンスチューニング
 
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
 
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】 Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
 
ソフトウェア工学2023 04 開発プロセスモデル
ソフトウェア工学2023 04 開発プロセスモデルソフトウェア工学2023 04 開発プロセスモデル
ソフトウェア工学2023 04 開発プロセスモデル
 
機械学習 - MNIST の次のステップ
機械学習 - MNIST の次のステップ機械学習 - MNIST の次のステップ
機械学習 - MNIST の次のステップ
 
Jenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめ
Jenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめJenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめ
Jenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめ
 
アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-
アジャイルテスト  -高品質を追求するアジャイルチームにおけるテストの視点-アジャイルテスト  -高品質を追求するアジャイルチームにおけるテストの視点-
アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-
 
設計/ドメイン設計(3) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第25回】
設計/ドメイン設計(3) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第25回】設計/ドメイン設計(3) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第25回】
設計/ドメイン設計(3) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第25回】
 
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
 
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
 
デブサミ関西2013【A4】コード品質は曖昧なままか(安竹由起夫氏)
デブサミ関西2013【A4】コード品質は曖昧なままか(安竹由起夫氏)デブサミ関西2013【A4】コード品質は曖昧なままか(安竹由起夫氏)
デブサミ関西2013【A4】コード品質は曖昧なままか(安竹由起夫氏)
 

Más de Hironori Washizaki

Machine Learning Software Engineering Patterns and Their Engineering
Machine Learning Software Engineering Patterns and Their EngineeringMachine Learning Software Engineering Patterns and Their Engineering
Machine Learning Software Engineering Patterns and Their EngineeringHironori Washizaki
 
IEEE Computer Society 2024 Technology Predictions Update
IEEE Computer Society 2024 Technology Predictions UpdateIEEE Computer Society 2024 Technology Predictions Update
IEEE Computer Society 2024 Technology Predictions UpdateHironori Washizaki
 
鷲崎弘宜, "国際規格ISO/IEC 24773とその意義", 情報処理学会 第86回全国大会
鷲崎弘宜, "国際規格ISO/IEC 24773とその意義", 情報処理学会 第86回全国大会鷲崎弘宜, "国際規格ISO/IEC 24773とその意義", 情報処理学会 第86回全国大会
鷲崎弘宜, "国際規格ISO/IEC 24773とその意義", 情報処理学会 第86回全国大会Hironori Washizaki
 
IEEE Computer Society’s Strategic Activities and Products including SWEBOK Guide
IEEE Computer Society’s Strategic Activities and Products including SWEBOK GuideIEEE Computer Society’s Strategic Activities and Products including SWEBOK Guide
IEEE Computer Society’s Strategic Activities and Products including SWEBOK GuideHironori Washizaki
 
TISO/IEC JTC1におけるソフトウェア工学知識体系、技術者認証および品質の標準化と研究・教育他への活用
TISO/IEC JTC1におけるソフトウェア工学知識体系、技術者認証および品質の標準化と研究・教育他への活用TISO/IEC JTC1におけるソフトウェア工学知識体系、技術者認証および品質の標準化と研究・教育他への活用
TISO/IEC JTC1におけるソフトウェア工学知識体系、技術者認証および品質の標準化と研究・教育他への活用Hironori Washizaki
 
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225Hironori Washizaki
 
Joseph Yoder : Being Agile about Architecture
Joseph Yoder : Being Agile about ArchitectureJoseph Yoder : Being Agile about Architecture
Joseph Yoder : Being Agile about ArchitectureHironori Washizaki
 
世界標準のソフトウェア工学知識体系SWEBOK Guide最新第4版を通じた開発アップデート
世界標準のソフトウェア工学知識体系SWEBOK Guide最新第4版を通じた開発アップデート世界標準のソフトウェア工学知識体系SWEBOK Guide最新第4版を通じた開発アップデート
世界標準のソフトウェア工学知識体系SWEBOK Guide最新第4版を通じた開発アップデートHironori Washizaki
 
SWEBOK Guide Evolution and Its Emerging Areas including Machine Learning Patt...
SWEBOK Guide Evolution and Its Emerging Areas including Machine Learning Patt...SWEBOK Guide Evolution and Its Emerging Areas including Machine Learning Patt...
SWEBOK Guide Evolution and Its Emerging Areas including Machine Learning Patt...Hironori Washizaki
 
デジタルトランスフォーメーション(DX)におけるソフトウェアの側面とダイバーシティ・インクルーシブに関する研究実践動向
デジタルトランスフォーメーション(DX)におけるソフトウェアの側面とダイバーシティ・インクルーシブに関する研究実践動向デジタルトランスフォーメーション(DX)におけるソフトウェアの側面とダイバーシティ・インクルーシブに関する研究実践動向
デジタルトランスフォーメーション(DX)におけるソフトウェアの側面とダイバーシティ・インクルーシブに関する研究実践動向Hironori Washizaki
 
人生100年・60年カリキュラム時代のDX人材育成: スマートエスイー 2021年度成果および2022年度募集
人生100年・60年カリキュラム時代のDX人材育成: スマートエスイー 2021年度成果および2022年度募集人生100年・60年カリキュラム時代のDX人材育成: スマートエスイー 2021年度成果および2022年度募集
人生100年・60年カリキュラム時代のDX人材育成: スマートエスイー 2021年度成果および2022年度募集Hironori Washizaki
 
スマートエスイーコンソーシアムの概要と2021年度成果紹介
スマートエスイーコンソーシアムの概要と2021年度成果紹介スマートエスイーコンソーシアムの概要と2021年度成果紹介
スマートエスイーコンソーシアムの概要と2021年度成果紹介Hironori Washizaki
 
DXの推進において企業内に求められる人材やデジタル人材の育て方
DXの推進において企業内に求められる人材やデジタル人材の育て方DXの推進において企業内に求められる人材やデジタル人材の育て方
DXの推進において企業内に求められる人材やデジタル人材の育て方Hironori Washizaki
 
対応性のある運用のパターン
対応性のある運用のパターン対応性のある運用のパターン
対応性のある運用のパターンHironori Washizaki
 
モデル訓練のパターン
モデル訓練のパターンモデル訓練のパターン
モデル訓練のパターンHironori Washizaki
 
パターンのつながりとAI活用成熟度
パターンのつながりとAI活用成熟度パターンのつながりとAI活用成熟度
パターンのつながりとAI活用成熟度Hironori Washizaki
 
データ表現のパターン
データ表現のパターンデータ表現のパターン
データ表現のパターンHironori Washizaki
 
機械学習デザインパターンの必要性と機械学習ライフサイクル
機械学習デザインパターンの必要性と機械学習ライフサイクル機械学習デザインパターンの必要性と機械学習ライフサイクル
機械学習デザインパターンの必要性と機械学習ライフサイクルHironori Washizaki
 
青山幹雄先生を偲んで(開拓、理論、実践、コミュニティ&国際)
青山幹雄先生を偲んで(開拓、理論、実践、コミュニティ&国際)青山幹雄先生を偲んで(開拓、理論、実践、コミュニティ&国際)
青山幹雄先生を偲んで(開拓、理論、実践、コミュニティ&国際)Hironori Washizaki
 
Software Engineering Patterns for Machine Learning Applications
Software Engineering Patterns for Machine Learning ApplicationsSoftware Engineering Patterns for Machine Learning Applications
Software Engineering Patterns for Machine Learning ApplicationsHironori Washizaki
 

Más de Hironori Washizaki (20)

Machine Learning Software Engineering Patterns and Their Engineering
Machine Learning Software Engineering Patterns and Their EngineeringMachine Learning Software Engineering Patterns and Their Engineering
Machine Learning Software Engineering Patterns and Their Engineering
 
IEEE Computer Society 2024 Technology Predictions Update
IEEE Computer Society 2024 Technology Predictions UpdateIEEE Computer Society 2024 Technology Predictions Update
IEEE Computer Society 2024 Technology Predictions Update
 
鷲崎弘宜, "国際規格ISO/IEC 24773とその意義", 情報処理学会 第86回全国大会
鷲崎弘宜, "国際規格ISO/IEC 24773とその意義", 情報処理学会 第86回全国大会鷲崎弘宜, "国際規格ISO/IEC 24773とその意義", 情報処理学会 第86回全国大会
鷲崎弘宜, "国際規格ISO/IEC 24773とその意義", 情報処理学会 第86回全国大会
 
IEEE Computer Society’s Strategic Activities and Products including SWEBOK Guide
IEEE Computer Society’s Strategic Activities and Products including SWEBOK GuideIEEE Computer Society’s Strategic Activities and Products including SWEBOK Guide
IEEE Computer Society’s Strategic Activities and Products including SWEBOK Guide
 
TISO/IEC JTC1におけるソフトウェア工学知識体系、技術者認証および品質の標準化と研究・教育他への活用
TISO/IEC JTC1におけるソフトウェア工学知識体系、技術者認証および品質の標準化と研究・教育他への活用TISO/IEC JTC1におけるソフトウェア工学知識体系、技術者認証および品質の標準化と研究・教育他への活用
TISO/IEC JTC1におけるソフトウェア工学知識体系、技術者認証および品質の標準化と研究・教育他への活用
 
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225
 
Joseph Yoder : Being Agile about Architecture
Joseph Yoder : Being Agile about ArchitectureJoseph Yoder : Being Agile about Architecture
Joseph Yoder : Being Agile about Architecture
 
世界標準のソフトウェア工学知識体系SWEBOK Guide最新第4版を通じた開発アップデート
世界標準のソフトウェア工学知識体系SWEBOK Guide最新第4版を通じた開発アップデート世界標準のソフトウェア工学知識体系SWEBOK Guide最新第4版を通じた開発アップデート
世界標準のソフトウェア工学知識体系SWEBOK Guide最新第4版を通じた開発アップデート
 
SWEBOK Guide Evolution and Its Emerging Areas including Machine Learning Patt...
SWEBOK Guide Evolution and Its Emerging Areas including Machine Learning Patt...SWEBOK Guide Evolution and Its Emerging Areas including Machine Learning Patt...
SWEBOK Guide Evolution and Its Emerging Areas including Machine Learning Patt...
 
デジタルトランスフォーメーション(DX)におけるソフトウェアの側面とダイバーシティ・インクルーシブに関する研究実践動向
デジタルトランスフォーメーション(DX)におけるソフトウェアの側面とダイバーシティ・インクルーシブに関する研究実践動向デジタルトランスフォーメーション(DX)におけるソフトウェアの側面とダイバーシティ・インクルーシブに関する研究実践動向
デジタルトランスフォーメーション(DX)におけるソフトウェアの側面とダイバーシティ・インクルーシブに関する研究実践動向
 
人生100年・60年カリキュラム時代のDX人材育成: スマートエスイー 2021年度成果および2022年度募集
人生100年・60年カリキュラム時代のDX人材育成: スマートエスイー 2021年度成果および2022年度募集人生100年・60年カリキュラム時代のDX人材育成: スマートエスイー 2021年度成果および2022年度募集
人生100年・60年カリキュラム時代のDX人材育成: スマートエスイー 2021年度成果および2022年度募集
 
スマートエスイーコンソーシアムの概要と2021年度成果紹介
スマートエスイーコンソーシアムの概要と2021年度成果紹介スマートエスイーコンソーシアムの概要と2021年度成果紹介
スマートエスイーコンソーシアムの概要と2021年度成果紹介
 
DXの推進において企業内に求められる人材やデジタル人材の育て方
DXの推進において企業内に求められる人材やデジタル人材の育て方DXの推進において企業内に求められる人材やデジタル人材の育て方
DXの推進において企業内に求められる人材やデジタル人材の育て方
 
対応性のある運用のパターン
対応性のある運用のパターン対応性のある運用のパターン
対応性のある運用のパターン
 
モデル訓練のパターン
モデル訓練のパターンモデル訓練のパターン
モデル訓練のパターン
 
パターンのつながりとAI活用成熟度
パターンのつながりとAI活用成熟度パターンのつながりとAI活用成熟度
パターンのつながりとAI活用成熟度
 
データ表現のパターン
データ表現のパターンデータ表現のパターン
データ表現のパターン
 
機械学習デザインパターンの必要性と機械学習ライフサイクル
機械学習デザインパターンの必要性と機械学習ライフサイクル機械学習デザインパターンの必要性と機械学習ライフサイクル
機械学習デザインパターンの必要性と機械学習ライフサイクル
 
青山幹雄先生を偲んで(開拓、理論、実践、コミュニティ&国際)
青山幹雄先生を偲んで(開拓、理論、実践、コミュニティ&国際)青山幹雄先生を偲んで(開拓、理論、実践、コミュニティ&国際)
青山幹雄先生を偲んで(開拓、理論、実践、コミュニティ&国際)
 
Software Engineering Patterns for Machine Learning Applications
Software Engineering Patterns for Machine Learning ApplicationsSoftware Engineering Patterns for Machine Learning Applications
Software Engineering Patterns for Machine Learning Applications
 

メトリクスによるソフトウェア品質評価・改善および製品品質実態

  • 2. TS-1TS-1 目次 • ソフトウェアの品質とメトリクス • ゴール指向の測定 GQMとGQM+Strategies • GQMに基づく組込みソフトウェア品質改善事例 • 国際規格と品質ベンチマーク 2 2
  • 3. TS-1TS-1 品質とは • 品質: あるものの特性または属性 [American Heritage Dictionary] • ソフトウェア品質: ソフトウェアの使用時に必要性 を満たす能力を決定する属性全体 [ISO9126- 1][ISO25000][JIS0129-1] – 属性: ソフトウェアの定性的/定量的に測定可能な特徴 • 品質モデル ISO/IEC 25010:2011 SQuaRE – 利用時の品質: 有効性、効率性、リスク回避性、満足 性、利用状況網羅性 – 製品品質(内部・外部品質): 機能適合性、互換性、セ キュリティ、信頼性、使用性、性能効率性、保守性、移 植性 3 3
  • 4. TS-1TS-1 メトリクス(Metric / Metrics) • 測定の方法と尺度 – 方法: 属性(測定可能な特徴)の尺度上の値や分類への対応 付け – 尺度: 値や分類の集合 – 対象: プロダクト、プロセス、リソース • 測定できない事柄は、管理できない(T. DeMarco) – ソフトウェア工学 = ソフトウェアの開発、運用、および保守に 対する系統的で規律に基づいた定量的アプローチ [SWEBOK] – Prj成功率 31% → 定量的評価導入Prj 46% [矢口08] …… …… …… 測定方法測定方法 測定尺度 測定プロセス メトリクス 測定結果 (値、分類) 4 [SWEBOK] 松本吉弘 監訳: ソフトウェアエンジニアリング基礎知識体系―SWEBOK2004, オーム社, 2005. [矢口08] 矢口竜太郎, 吉田洋平: 成功率は31.1%, 日経コンピュータ12月1日号, 2008. 4
  • 5. TS-1TS-1 測定方法 • ソフトウェアの抽象的な特定側面を捉える • 測定方法が異なれば測定結果も変わる • 定義方法: テキスト、図、数式 1:/* strncat()は、文字列srcからcount数の文字を文字列destに付加し、さ 2:らに終端にnull文字を付加する。重なるオブジェクト間でコピーしようとする 3:場合、動作は未定義である。*/ 4:char *strncat(char *dest, const char *src, size_t count) 5:{ 6: char *temp=dest; 7: if (count) { 8: while (*dest) 9: dest++; 10: while ((*dest++=*src++)) { 11: if (--count ==0) { 12: *dest=‘¥0’; break; 13: } 14: } 15: } return temp; 16:} 5 5
  • 6. TS-1TS-1 メトリクスの使いどころ • 現在 – 把握、評価 – ヒストグラム、管理図ほか • 未来 – 予測、計画 – 散布図、回帰分析ほか 要求 定義 設計 実装 テスト 機能 仕様書 ファンクション ポイント モジュール 設計 凝集度 結合度 ソース コード 複雑度 コード行数 欠陥票 欠陥密度 テスト ケース 消化数 工数、期間 件 数 測定値 例: サイクロマティック複雑度 被使用外部ファイル率 関数 再利 用率 鷲崎弘宜,田邉浩之,小池利和,ソースコード解析による品質評価の仕組み,日経エレクトロニクス 2010/1/25 鷲崎弘宜, 小池利和, 波木理恵子, 田邉浩之, "C言語プログラムソースコードの再利用性測定法とその評価", ソフトウェアテストシンポジウム JaSST'09 6
  • 7. TS-1TS-1 主なメトリクス 名称 定義 用途 コード行数(LOC) コードの行数 規模の把握、他のメトリ クスの正規化 ファンクションポイン ト(FP) 機能量 規模の見積もり サイクロマティック複 雑度(CC) 制御フローグラフの経路 数 複雑さの把握 凝集度 モジュール内の要素のま とまり 複雑さの把握 結合度 モジュール間の結合関係 の多さ 複雑さの把握 欠陥密度(DD) 欠陥数 / 新規・変更LOC 品質の把握、開発プロセ ス全体の有効性把握 欠陥除去率(DRE) 欠陥摘出数 / 当該時点 欠陥数 開発プロセス全体や工 程の有効性把握 消化済みテストケー ス数 当該時点までの消化済 みテストケース数 テストの進捗把握 プロダクト プロセス 7 7
  • 8. TS-1TS-1 目次 • ソフトウェアの品質とメトリクス • ゴール指向の測定 GQMとGQM+Strategies • GQMに基づく組込みソフトウェア品質改善事例 • 国際規格と品質ベンチマーク 8 8
  • 9. 落とし穴「ホーソン効果」 9nicolasdsampson.com, Observe And Learn: The Magic Of Paying Attention http://nicolasdsampson.com/wp-content/uploads/2012/10/2010_12_06_observe-learn-magic-paying-attention.jpg
  • 10. TS-1TS-1 コツ: Goal-Question-Metric (GQM) • 明確に目標を据えて、目標に対して必要なメトリクスを対応 付けるゴール指向(目標指向)な枠組み • 目標(Goal): 測定上の目標 • 質問(Question): 目標の達成を評価するための質問 • メトリクス(Metric): 質問に回答するために必要な定量的デ ータを得るための主観的・客観的メトリクス 測定する事柄 の決定 測定結果の 解釈 M. メトリクス G. 目標 Q. 質問 収集データ 目標達成評価 答え 測定値 R. van Solingen, E. Berghout, “The Goal/Question/Metric Method” McGraw-Hill Education, 1999; ISBN 0-07709-553-7. 10 10
  • 11. TS-1TS-1 GQMモデル(グラフ)の例 • 目標 – G. コードクローン含有の観点から保守性の低いコードを 特定できている。 • 質問 – Q1: コードクローンは存在するか? → M1, M2 – Q2: 発見されたコードクローンは保守上有害か? → M3 • メトリクス – M1: ソースコードの全体的な重複度 – M2: モジュール単位のコードクローン含有率 – M3: コードクローンに対するマネージャの主観的評価 11 G Q1 Q2 M1 M2 M3 楠本真二, 肥後芳樹, “GQMパラダイムを用いたソフトウェアメトリクスの活用”, コンピュータソフトウェア, 2012. V. Basili, et al.: Goal, Question, Metric Paradigm, Encycloperia of Software Engineering, Vol. 1(1994) リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの", 日経BP社 , 2009. 11
  • 12. TS-1TS-1 目標テンプレートとコンテキスト • 目標の一般性、扱う範囲の明確化 • テンプレート – 例: コードクローン含有の観点から保守性の低いコードを 特定できている。 – 対象 (Analyze) 例: ソースコード – 目的 (Purpose) 例: 保守性の低いコードの特定 – 関心 (Respect to) 例: コードクローン情報 – 視点 (View) 例: プロジェクトマネージャ – 環境 (Context) 例: A社の開発環境 • 環境 – ドメイン、開発者数、経験、開発プロセス・手法、規模・工 数、信頼性要求、・・・ 12 楠本真二, 肥後芳樹, “GQMパラダイムを用いたソフトウェアメトリクスの活用”, コンピュータソフトウェア, 2012. V. Basili, et al.: Goal, Question, Metric Paradigm, Encycloperia of Software Engineering, Vol. 1(1994) リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの", 日経BP社 , 2009. 12
  • 13. TS-1TS-1 質問導出の観点 • 測定対象そのものを目的から見て明確にする – 例: ○○はいくらか? • 対象の属性を評価者の視点から見て明確にす る – 例: ○○は(従来と比べて)改善されているか? • 対象の特徴を評価者の視点から見て評価する – 例: ○○は××からみて目に見えて改善されている か? 13 楠本真二, 肥後芳樹, “GQMパラダイムを用いたソフトウェアメトリクスの活用”, コンピュータソフトウェア, 2012. 13
  • 14. TS-1TS-1 仮定と解釈 • 仮定(Hypothesis, Assumption) – Question導出にあたり仮定している事柄 – 例 A. 要求が不安定であれば設計は頻繁に変更される。 – 測定評価の繰り返しにおける見直し • 解釈(Interpretation) – もし「条件式」ならば「Goalは達成・未達成である」 – 例 I. もしLOCが少なすぎず、かつ、設計変更回数が一 定以上ならば、要求が不安定な可能性がある。 – 多面的な捉え方 – 閾値の明確化: ベンチマーク分布、経験ベース、欠陥と の照らし合わせなど [Alves10]、最初は大まかに&デー タ蓄積と現物確認を経て精密に リンダ・M・ライルドほか著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの基礎 ソフトウエアの測定と見積もりの正しい作法", 日経BP社 , 2009. Monden, Basili, et al.: Customizing GQM Models for Software Project Monitoring, IEICE Trans., 2012. Tiago L. Alves, et al., “Deriving Metric Thresholds from Benchmark Data,” ICSM 2010 14
  • 15. TS-1TS-1 GQMの拡張: 仮定と解釈 15 Monden, Basili, et al.: Customizing GQM Models for Software Project Monitoring, IEICE Trans., 2012. G. 特定プロジェクトにおける要求の不安定さを把握できている Q. ソースファイルの 変更頻度はいくらか? Q. ファイルの変更 規模はいくらか? FCt. 一週間以内の ファイル更新回数 FCd. 一週間以内の削除 を伴うファイル更新回数 FLa. 一週間以 内の追加行数 A. 要求が不安定であれば コードは頻繁に削除を 伴って変更される A. 要求が不安定であれば コードは大きく変更される FLd. 一週間以 内の削除行数 I. FCt が極端に大きくなく、かつ、 FCdが以前よりも大きいのであれ ば、要求が不安定な可能性あり I. FLa が極端に大きくなく、かつ、 FLdが以前よりも大きいのであれ ば、要求が不安定な可能性あり ・・・ 15
  • 18. TS-1TS-1 測定プログラム運用プロセス 18 6 パッケージ化と改善 目標と戦略を適合し改善 背景と仮定の是正 学習の記録 0 初期化 コミットメント 人材 & 責任 5 結果の分析 ・データを分析し、戦略を改定 ・結果のレビューと伝達 ・コスト/メリットの分析 1 特性化(Characterize) ・適用範囲の定義 ・環境/事実の特性化 2 目標設定 ・組織構造を特定(determine) ・ギャップ分析の実施 ※現状の施策、データ等の確認 ・目標の優先順位づけ ・グリッド導出(derivation)プロセスの実施 3 プロセスの選択 ・戦略実施の計画 ・データ収集と分析の仕方の整理 ・フィードバックの仕組みの定義 4 モデルの実行 ・戦略の適用 ・データの収集と検証 ・フィードバックセッションの実施 Jens Heidrich, Adam Trendowicz, IPA訳, 測定を基にしたソフトウェア戦略とビジネス目標の整合, 2012 18
  • 20. TS-1TS-1 コツ「データと機械学習による改善(PDCA)」 20 10 25 300 150 M. 関数の数 M.実行行数 OK NG 71 M. 関数の数 M.実行行数 OK NG △ OK, ○ NG N. Tsuda, H. Washizaki, et al., Machine Learning to Evaluate Evolvability Defects: Code Metrics Thresholds for a Given Context, QRS2018 コマツとの共同研究 20
  • 21. TS-1TS-1 目次 • ソフトウェアの品質とメトリクス • ゴール指向の測定 GQMとGQM+Strategies • GQMに基づく組込みソフトウェア品質改善事例 • 国際規格と品質ベンチマーク 21 21
  • 22. TS-1TS-1 コツ「横に広げて多面的に見る」 22 鷲崎弘宜,田邉浩之,小池利和,ソースコード解析による品質評価の仕組み,日経エレクトロニクス 2010/1/25 [Adqua] http://www.ogis-ri.co.jp/product/b-08-000001A6.html 保守性 モジュール性 再利用性 修正性 ・・・ コールグラフ 階層の深さ サイクロマテ ィック複雑度 関数内の 戻り点の数 処理が複雑 すぎないか? 処理が構造化 されているか? …… … …… … …… … …… … ・・・ ・・・ ・・・ G. 目標 対象 M. メトリクス Q. 質問 22
  • 23. TS-1TS-1 対象例: ETロボコン・コード改善 • 規模: 1481 ELOC, 18クラス, 121関数 • サイクロマティック複雑度の大きい関数をリストアップ • しかし「数」だけでは問題は分からない → 対象の詳細調査へ 23 保守性 得点 78.6 偏差値 36.1 解析性 得点 79.3 偏差値 38.7 変更性 得点 89.3 偏差値 46.2 安定性 得点 84.3 偏差値 50.0 試験性 得点 61.5 偏差値 35.8 品質特性 品質副特性 ファイル名 関数名 サイクロマ ティック複雑度 関数の 物理行数 Magi.cpp decideSynthetic() 12 55 Tactics.cpp getDriver(DriveStatus::eDifficultKind) 12 51 StepDriver.cpp drive(bool) 11 119 SeesawDriver.cpp drive(bool) 8 100 GarageDriver.cpp driveIn(void) 8 73 Main.cpp TASK(TaskDrive) 7 91 Magi.cpp getDriveStatus() 7 37 PositionDecision.cpp updateLocation() 6 81 Tactics.cpp ~Tactics(void) 5 15 ファイル名 関数名 サイクロマ ティック複雑度 関数の 物理行数 Magi.cpp decideSynthetic() 12 55 Tactics.cpp getDriver(DriveStatus::eDifficultKind) 12 51 StepDriver.cpp drive(bool) 11 119 SeesawDriver.cpp drive(bool) 8 100 GarageDriver.cpp driveIn(void) 8 73 Main.cpp TASK(TaskDrive) 7 91 Magi.cpp getDriveStatus() 7 37 PositionDecision.cpp updateLocation() 6 81 Tactics.cpp ~Tactics(void) 5 15 Question 得点 偏差値 メトリック 得点 処理が複雑すぎないか 44.5 37.7 制御フローグラフの最大ネスト数 40.9 サイクロマティック複雑度 46.8 処理が構造化されているか 99.5 46.5 break等のないswitch文の数 91.0 要素間の結合度は低くなって いるか 75.9 48.1 使用する他クラスの種類数 69.3 自クラスを使用する他クラスの種類数 70.4 要素の規模は適切か 59.1 43.7 関数の実行コード行数 34.5 クラスの実行コード行数 35.6 ファイル内の関数の数 85.6 クラス内のメソッド数 78.1 鷲崎, 阿佐美, 田邉, ETロボコンの事例で学ぶモデル活用の効能: 第2回参加チームの事例,日経エレクトロニクス, 2011年9月5日
  • 24. TS-1TS-1 //============================================================================= // 走行ステータスに応じて走行クラスを返却 Driver* Tactics::getDriver(DriveStatus::eDifficultKind kind) { Driver* drive; drive = 0; switch(kind) { case DriveStatus::LINETRACE: if(mLineTraceDriver == 0) { mLineTraceDriver = new LineTraceDriver(mMaimai, mPid); } drive = mLineTraceDriver; break; case DriveStatus::SEESAW: if(mSeesawDriver == 0) { mSeesawDriver = new SeesawDriver(mrGyro, mMaimai, mPid); } drive = mSeesawDriver; break; case DriveStatus::STEPS: if(mStepDriver == 0) { mStepDriver = new StepDriver(mrGyro, mMaimai, mPid); } drive = mStepDriver; break; case DriveStatus::OUTCOURSE_GARAGE: if(mGarageDriver == 0) { mGarageDriver = new GarageDriver(mPositionDecision); } drive = mGarageDriver; break; case DriveStatus::INCOURSE_GARAGE: if(mGarageDriver == 0) { mGarageDriver = new GarageDriver(mPositionDecision); } drive = mGarageDriver; break; default: if(mLineTraceDriver == 0) { mLineTraceDriver = new LineTraceDriver(mMaimai, mPid); } drive = mLineTraceDriver; break; } return drive; } //============================================================================= // 走行ステータスに応じて走行クラスを返却 Driver* Tactics::getDriver(DriveStatus::eDifficultKind kind) { Driver* drive; drive = 0; switch(kind) { case DriveStatus::LINETRACE: if(mLineTraceDriver == 0) { mLineTraceDriver = new LineTraceDriver(mMaimai, mPid); } drive = mLineTraceDriver; break; case DriveStatus::SEESAW: if(mSeesawDriver == 0) { mSeesawDriver = new SeesawDriver(mrGyro, mMaimai, mPid); } drive = mSeesawDriver; break; case DriveStatus::STEPS: if(mStepDriver == 0) { mStepDriver = new StepDriver(mrGyro, mMaimai, mPid); } drive = mStepDriver; break; case DriveStatus::OUTCOURSE_GARAGE: if(mGarageDriver == 0) { mGarageDriver = new GarageDriver(mPositionDecision); } drive = mGarageDriver; break; case DriveStatus::INCOURSE_GARAGE: if(mGarageDriver == 0) { mGarageDriver = new GarageDriver(mPositionDecision); } drive = mGarageDriver; break; default: if(mLineTraceDriver == 0) { mLineTraceDriver = new LineTraceDriver(mMaimai, mPid); } drive = mLineTraceDriver; break; } return drive; } //============================================================================= // 難所走行状態の更新 void Magi::decideSynthetic() { // 次に目指す難所を取得 ChangePoint p = mStrategy.getChangePoint(); // 事前に登録した判定クラスから難所を取得 int decideCount = 0; for (SINT i = 0; i < mNumOfJudge; i++) { if (mJudgeAddressTable[i]->decideHard(p)) { decideCount++; } } if (decideCount >= 1) { switch (p.getPointKind()) { case ChangePoint::SEESAW_IN: mDifficultKindBuf = DriveStatus::SEESAW; mCangeCount = 0; break; case ChangePoint::SEESAW_OUT: mDifficultKindBuf = DriveStatus::LINETRACE; mCangeCount = 0; break; case ChangePoint::STEPS_IN: mDifficultKindBuf = DriveStatus::STEPS; mCangeCount = 0; break; case ChangePoint::STEPS_OUT: mDifficultKindBuf = DriveStatus::LINETRACE; mCangeCount = 0; break; case ChangePoint::OUTCOURSE_GARAGE: mDifficultKindBuf = DriveStatus::OUTCOURSE_GARAGE; mCangeCount = 0; break; case ChangePoint::INCOURSE_GARAGE: mDifficultKindBuf = DriveStatus::INCOURSE_GARAGE; mCangeCount = 0; break; default: break; } // 目指す難所を更新する mStrategy.next(); } // 難所判定後、時間差で走行を切替えるケースに備える if (mCangeCount > 0) { mCangeCount--; } else if (mCangeCount == 0) { mCangeCount--; // 走行切替 mStatus.setDifficultKind(mDifficultKindBuf); } } //============================================================================= // 難所走行状態の更新 void Magi::decideSynthetic() { // 次に目指す難所を取得 ChangePoint p = mStrategy.getChangePoint(); // 事前に登録した判定クラスから難所を取得 int decideCount = 0; for (SINT i = 0; i < mNumOfJudge; i++) { if (mJudgeAddressTable[i]->decideHard(p)) { decideCount++; } } if (decideCount >= 1) { switch (p.getPointKind()) { case ChangePoint::SEESAW_IN: mDifficultKindBuf = DriveStatus::SEESAW; mCangeCount = 0; break; case ChangePoint::SEESAW_OUT: mDifficultKindBuf = DriveStatus::LINETRACE; mCangeCount = 0; break; case ChangePoint::STEPS_IN: mDifficultKindBuf = DriveStatus::STEPS; mCangeCount = 0; break; case ChangePoint::STEPS_OUT: mDifficultKindBuf = DriveStatus::LINETRACE; mCangeCount = 0; break; case ChangePoint::OUTCOURSE_GARAGE: mDifficultKindBuf = DriveStatus::OUTCOURSE_GARAGE; mCangeCount = 0; break; case ChangePoint::INCOURSE_GARAGE: mDifficultKindBuf = DriveStatus::INCOURSE_GARAGE; mCangeCount = 0; break; default: break; } // 目指す難所を更新する mStrategy.next(); } // 難所判定後、時間差で走行を切替えるケースに備える if (mCangeCount > 0) { mCangeCount--; } else if (mCangeCount == 0) { mCangeCount--; // 走行切替 mStatus.setDifficultKind(mDifficultKindBuf); } } 24 鷲崎, 阿佐美, 田邉, ETロボコンの事例で学ぶモデル活用の効能: 第2回参加チームの事例,日経エレクトロニクス, 2011年9月5日
  • 25. TS-1TS-1 「数」から問題・原因の特定へ • 散らばり or もつれあい • 「難所に関する処理・責務(関心事)」のパッケージ横断な散らばり 25 コンポーネント ECROBOT API 走行系 判定処理系 3重多数決 + 走行ステータス更新() : 走行ステータス + 開始判定() : boolean + 総合判定() : void 戦略 + 目標切替ポイント取得() : 切替ポイント 切替ポイント - 灰色検知フラグ - 座標 - 推定時間 審判 + 難所判定(切替ポイント) : boolean + フェイルセーフ判定(走行ステータス) : boolean 時間判定 - 現在時間 + 時間判定(推定時間) : void - 時間更新() : void 位置判定 - 現在位置 + ロケーション判定(座標) : void - 現在位置更新() : void 色判定 - 現在色 + 灰色検知(灰色検知フラグ) : void - 現在色更新() : void Main + 初期化() : void + 走行開始() : void 走行ステータス - IN/OUTフラグ + getter() : void + setter() : void <<enum>> 走行種別 - キャリブレーション - 走行 - 停止 <<enum>> 難所種別 - ライントレース - 階段 - シーソー通過 - ガレージイン 戦術 - 走行 + 走行クラス取得(走行ステータス) : 走行 走行 + 走る() : void ライントレース走行 階段走行 シーソー通過走行 ガレージイン走行 ロケーション + 現在座標取得() : void まいまい式 - 補正ライトセンサ値 - 定周期ライトON() : void - 定周期ライトOFF() : void + 補正ライトセンサ値取得() : void PID制御 - PID算出() : void + 進行方向取得() : 進行方向 インテリジェントモーター - 補正係数 + モーター出力補正() : void + モーター出力設定(右出力, 左出力) : void タッチセンサ + センサ値取得() : boolean タイマー + 時間取得() : 時間 ジャイロセンサ + センサ値取得() : ジャイロセンサ値 ライトセンサ + センサ値取得() : ライトセンサ値 + ランプ設定(ON/OFF) : void モーター + モーター出力設定(出力) : void + 回転数取得() : 回転数 1 走行クラスを 取得する 1 切替ポイントを 取得する * 1 3 難所を判定する 1 走行ステータスを取得する 1 走る 4 生成する 1 センサ値を 取得する 1 1 時間を取得 する 1 1 現在座標を 取得する 1 1 センサ値を 取得する 1 1 ライトセンサ値を 取得する 1 1 センサ値を 取得する 1 1 モーター値を設定する 2 1 モーター値を 設定する 1 1 進行方向を 取得する 1 1 ライトセンサ値を 取得する 1 1 回転数を取得する 2 鷲崎, 阿佐美, 田邉, ETロボコンの事例で学ぶモデル活用の効能: 第2回参加チームの事例,日経エレクトロニクス, 2011年9月5日
  • 26. TS-1TS-1 改善結果 26 走行系判定処理系 3重多数決 + 難所判定(切替ポイント) : boolean 切替ポイント - 灰色検知フラグ - 座標 - 推定時間 審判 + 難所判定(切替ポイント) : boolean + フェイルセーフ判定(走行ステータス) : boolean 時間判定 - 現在時間 + 時間判定(推定時間) : void - 時間更新() : void 位置判定 - 現在位置 + ロケーション判定(座標) : void - 現在位置更新() : void 色判定 - 現在色 + 灰色検知(灰色検知フラグ) : void - 現在色更新() : void Main + 初期化() : void + 走行開始() : void 走行ステータス - IN/OUTフラグ + getter() : void + setter() : void <<enum>> 走行種別 - キャリブレーション - 走行 - 停止 戦術 - 走行 + 走行開始() : void 走行 + 走る() : void + 切替ポイント取得(IN/OUT) : 切替ポイント ライントレ ース走行 階段走行 シーソー通過走行 ガレ ージイン走行 1 1 3 難所を判定する 1 1 難所を判定する 1 1 1 +構成要素1..* {ordered} 1 +出時0..1 1 +入時0..1 1 1 走行を開始する 1 Question 得点 偏差値 メトリック 得点 処理が複雑すぎないか 52.0 42.7 制御フローグラフの最大ネスト数 48.0 サイクロマティック複雑度 55.2 処理が構造化されているか 98.7 46.1 break等のないswitch文の数 90.8 要素間の結合度は低くなって いるか 75.6 47.9 使用する他クラスの種類数 68.8 自クラスを使用する他クラスの種類数 67.7 要素の規模は適切か 62.7 47.4 関数の実行コード行数 37.6 クラスの実行コード行数 39.6 ファイル内の関数の数 87.6 クラス内のメソッド数 81.1 7.5 UP 3.6 UP 7.1 UP 8.4 UP 3.1 UP • 関心事の局 所化 • 保守性改善 鷲崎, 阿佐美, 田邉, ETロボコンの事例で学ぶモデル活用の効能: 第2回参加チームの事例,日経エレクトロニクス, 2011年9月5日
  • 27. TS-1TS-1 目次 • ソフトウェアの品質とメトリクス • ゴール指向の測定 GQMとGQM+Strategies • GQMに基づく組込みソフトウェア品質改善事例 • 国際規格と品質ベンチマーク 27 27
  • 30. TS-1TS-1 コツ「国際規格の活用」 30 ISO/IEC 25023 内部・外部品質測定 ISO/IEC 25023 内部・外部品質測定 利用時の 品質 利用時の 品質 外部品質外部品質内部品質内部品質 ソフトウェア システム 業務 …… …… …… …… …… …… どのように 影響? ISO/IEC 25022 利用時の品質測定 ISO/IEC 25022 利用時の品質測定 ISO/IEC 25051 既製ソフト品質要求ISO/IEC 25051 既製ソフト品質要求 ISO/IEC 25010 品質モデルISO/IEC 25010 品質モデル 現実の入力から どのように 測定評価 すればよいか? • PSQ認証 – コンピュータソフトウェア協会(CSAJ) – カタログ、マニュアル、仕様書、試験文書 – 全品質特性 30
  • 31. TS-1TS-1 IPA RISE委託研究: 測定評価と分析によるソフトウェア製 品品質の実態定量化および総合的品質評価枠組みの確立 31 • 21製品個別評価と業界実態分析 • 国際標準ベンチマークへ Waseda Software Quality Benchmark (WSQB2017) http://www.washi.cs.waseda.ac.jp/wsqb/ SEC journal, Vol. 14, No. 1, 2018 • 国際規格 ISO/IEC 25000 SQuaRE シリーズを具体化 • 製品品質、利用時品質の網羅 と関係分析 0 20 40 60 80 100 機能適合性 性能効率性 互換性 使用性 信頼性 セキュリティ 保守性 移植性 0 5 10 1 2 3 4 5 6 12ベンダ 21製品 4評価機関 一部委託 一部結果 ISO/IEC JTC1/SC7/WG6 SQuaREエディタ 協力 評価結果
  • 32. TS-1TS-1 品質測定評価の枠組み 32 Q1. 社内サーバのみ使用する経路は? Q2. 社外サーバも使用する経路は? Q3. クライアント間直接通信(P2P等)は? Q4. 申請者管理サーバ使用の経路は? G.情報アクセスや情報伝達などの 行為とその内容が偽って否認され ないようにシステムができている M. 署名経路率 = 署名経路数 / 各種別の経路数 例: 否認防止性 研究チーム 製品提供元 1 GQM法でSQuaREメ トリクス具体化 2 測定ツール化(様 式、コード解析、アン ケート・テスト) 3 コード解析実施、 ユーザテスト実施 様式記入、ア ンケート回収 4 測定値・スコア計算、 診断、集計 パーセンタイルによるスコア化 例: 全体のうち70%の製品群よりも上 = 0.7 対応言語 認証方式 配備形態 不具合情報 試験情報 機能情報※ DB情報※ NW情報※ コード※ 運用情報※ (※任意) 高低 件 数 測定値
  • 33. TS-1TS-1 33 機能適合性 性能効率性 互換性 使用性 信頼性 セキュリティ 保守性 移植性 有効性 効率性 満足性 リスク回避性 利用状況網羅性 • 信頼性: 全体的に同程度 • 使用性、保守性: 低いほうにやや集中 • 互換性: 2極化、データ交換を一部考慮せず • セキュリティ: 2極化、暗号化や破損防止に差あり • 有効性、効率性: 2極化、タスク実行に一部難あり
  • 34. TS-1TS-1 品質特性間の関係分析 34 製品品質 利用時の品質 p値<0.1p値<0.1 性能効率性 互換性 使用性 信頼性 セキュリティ 保守性 移植性 有効性 効率性 満足性 リスク回避性 利用状況網羅性 機能適合性 0. 31 0. 19 -0. 72 0. 37 -0. 05 0. 50 0. 31 -0. 14 0. 52 1. 00 1. 00 1. 00 性能効率性 0. 44 0. 24 0. 36 -0. 17 0. 37 0. 32 0. 32 -0. 10 -0. 50 -0. 50 -0. 50 互換性 0. 04 0. 17 -0. 06 0. 36 -0. 04 -0. 14 0. 05 -0. 50 -0. 50 -0. 50 使用性 0. 17 -0. 21 0. 11 0. 44 -0. 09 -0. 20 -1. 00 -1. 00 -1. 00 信頼性 0. 30 0. 41 0. 45 -0. 08 0. 11 1. 00 1. 00 1. 00 セキュリティ -0. 06 0. 19 0. 64 -0. 34 0. 50 0. 50 0. 50 保守性 0. 26 -0. 29 0. 01 1. 00 1. 00 1. 00 移植性 -0. 21 0. 67 0. 50 0. 50 0. 50 有効性 0. 03 -1. 00 -1. 00 -1. 00 効率性 1. 00 1. 00 1. 00 満足性 1. 00 1. 00 リスク回避性 1. 00 • 信頼性が高いほど、保守性や移植 性も高い – 高信頼製品ほど長期にわたる保守や 様々な環境への移植や適合が求めら れる可能性 • 移植性が高いほど、使用性や効率 性が高い • セキュリティが高いほど、有効性も高 い • 機能適合性が高いほど、使用性が 低い – 副作用、使用性軽視の可能性 • 信頼性が高いほど、保守性や移植 性も高い – 高信頼製品ほど長期にわたる保守や 様々な環境への移植や適合が求めら れる可能性 • 移植性が高いほど、使用性や効率 性が高い • セキュリティが高いほど、有効性も高 い • 機能適合性が高いほど、使用性が 低い – 副作用、使用性軽視の可能性
  • 35. TS-1TS-1 互換性性能効率性機能適合性 安定 漸増 爆発 信頼性 有効性 信頼性モデル: 発見時間と数の関係を分析し欠陥数を予測 爆発(3)漸増(3)安定(3製品) • 機能適合性、有効性: 安定 で高品質 • 性能効率性、互換性: 爆発 において低品質 • 他の特性: 信頼性タイプで相 違無し
  • 36. TS-1TS-1 コンテキスト別の分析 36 • ドメイン別: 互換性、セキュリ ティに顕著な差 • パッケージ製品: セキュリテ ィ強化が課題 • クラウド製品: 移植性、保守 性、信頼性の測定方法が不 適当な可能性 • 規模、期間、開発形態: 顕著 な相違無し 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 機能 適… 性能 効… 互換 性 使用 性 信頼 性 セ キ… 保守 性 移植 性 有効 性 効率 性 満足 性 リスク 回… 利用 状… グループ支援 (n=5) データ集計(n=5) 会計(n=4) セキュリティ(n=3) 数値計算シミュ レーション(n=3) エンドユーザ向け サービス(n=1) 区別なし(n=21) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 機能 適… 性能 効… 互換 性 使用 性 信頼 性 セキュ リティ 保守 性 移植 性 有効 性 効率 性 満足 性 リスク 回… 利用 状… パッケージ (n=17) クラウド(n=4) 区別なし (n=21) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 機能適合性 性能効率性 互換性 使用性 信頼性 セキュリティ 保守性移植性 有効性 効率性 満足性 リスク回避 性 利用状況網 羅性 0-10K(n=2) 10K-50K(n=6) 50K-100K(n=2) 100K-(n=6) 区別なし(n=16)
  • 37. TS-1TS-1 37 ベンチマークによりポジショニング 確認ができ、該当製品が目指し た強みが実現できた 小島嘉津江,森田純恵,廣瀬竹男,若本雅晶 ,菊池慎司,楾晃歓,鷲崎弘宜, “ソフトウェ ア品質技術が品質特性に与える効果の見える 化とその検証”, SEC journal, Vol. 14, No. 1, pp. 50-57, 2018. 活用: 富士通グループの事例 有効性 効率性 満足性 リスク回避 性 利用状況 網羅性 機能適合 性 性能効率 性 互換性 使用性 信頼性 セキュリティ 保守性 移植性 データ処理能力重視 ○ ○ ○ ◎ ○ ○ △ ○ 早期デリバリー △ △ △ × × 利用時の品質 システム/ソフトウェア製品品質 プロジェクト要件 要件を満たすための品質特性 (最優先:◎→○→△→×:低優先)注力する品質特性を決定 時間効率性 の試験有無 応答時間平 均 応答時間実 測対目標 ターンアラウン ドタイム平均 ターンアラウン ドタイム実測 対目標 スループット目 標達成率 資源効率性 の試験有無 CPU使用率 最大値 メモリ使用率 最大値 容量満足性 の試験有無 ユーザ同時ア クセス可能数 目標達成率 大or小が望ましい 大 小 小 小 小 大 大 小 小 大 大 メトリクス測定値 1 - - - - 2.08 1 0.03 NA 1 NA - ログイン画面 表示 - プロセス起動 - データ蓄積 - データ保存 データ保存 - ユーザ数 - - - データ検索 (500件) - - - データ検索 データ検索 - - RISEメトリクス(性能効率性) 測定条件 (サンプル) メトリクスにより品質達成度評価 RISEベンチマークによるポジショニング評価
  • 38. TS-1TS-1 まとめ、メッセージ • ソフトウェア開発の厳しさとメトリクスの重要性 – 開発の管理、品質把握と改善 • メトリクスの限界を知り意思決定に役立てる – 測定方法、信頼性、妥当性、負のホーソン効果 • GQMによるゴール指向の測定 – 測定と改善のプロセス – アクションに向けて: GQM+Strategies • 応用 – GQMを用いた組込みソフトウェア品質改善 – 品質ベンチマーク WSQF 38 38
  • 39. TS-1TS-1 参考資料• メトリクス全般 – リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの基礎 ソフトウエアの測定 と見積もりの正しい作法", 日経BP社 , 2009. • GQM – 鷲崎弘宜、”ゴール指向の測定評価と留意 – GQMパラダイムと 拡張 -”、メトリクス公団、Vol.1、TEF東海メトリクス勉強会、2013. – 楠本真二、肥後芳樹: “GQMパラダイムを用いたソフトウェアメトリ クスの活用”、コンピュータソフトウェア、29(3)、pp.29-38、2012. • GQM+Strategies – 早稲田大学ゴール指向経営研究会、「残念なシステム」のなくしか た、日経ITPro、連載、2014年5月14日~6月11日 – Victor Basili, Adam Trendowicz, Martin Kowalczyk, Jens Heidrich, Carolyn Seaman, Jürgen Münch, Dieter Rombach 著, 鷲崎弘宜, 小堀貴信, 新谷勝利, 松岡秀樹 監訳, 早稲田大学 グローバルソフトウェアエンジニアリング研究所ゴール指向経営研 究会 訳, “ゴール&ストラテジ入門: 残念なシステムの無くし方 (GQM+Strategies)”, オーム社, 2015年9月10日発行 • 事例 – 鷲崎弘宜, 田邉浩之, 小池利和, “ソースコード解析による品質評 価の仕組み”, 日経エレクトロニクス, 2010年1月25日号, 2010. – 鷲崎弘宜, 阿左美勝, 田邉浩之, “モデル活用の効能: 第1回 モデ ルを書く意味”~ “モデル活用の効能: 第4回 参加チームの事例 3″,日経エレクトロニクス, 日経BP社, 2011年8月8日号~11月号 39 39
  • 40. TS-1 ご紹介: enPiT-Pro スマートエスイー 40 ⚫ 文部科学省社会人教育事業 ‘17-’21 (代表: 鷲崎) http://smartse.jp/ ⚫ 12月10日(月) スマートエスイー シンポジウム クラウド センサ・IoT 人工 知能 ビッグ データ 生成 知識 抽出 革新 アプリケーション ビジネス 価値 創造 通信・物理 情報処理 総合実践 連携校(13校) 茨城大学 群馬大学 東京学芸大学 東京工業大学 大阪大学 九州大学 工学院大学 東京工科大学 東洋大学 鶴見大学 北陸先端科学技術大学院大学 奈良先端科学技術大学院大学 情報・システム研究機構 (国立情報学研究所) 協力校(2校) 立命館大学 The BigClouT Project 教材・指導 地区展開 進学・共同 研究接続 連携企業・業界団体(23団体) 日本電気 富士通 日立製作所 東芝 いい生活 ヤフー モバイルコンピューティング推進コンソーシアム 次世代センサ協議会 日本IT団体連盟 IT検証産業協会 コンピュータソフトウェア協会 組込みシステム技術協会 電子情報技術産業協会 全脳アーキテクチャ・イニシアティブ 新経済連盟 先端IT活用推進コンソーシアム 日本オープンオンライン教育推進協議会 デンソー ハレックス 情報医療 システム情報 題材・事例 教材・指導 受講生派遣 外部評価 想定受講者 情報系の一定知識を 持っている人 組込み・ IoTプロフェッショナル クラウド・ ビジネスイノベー ター システムオブシステムズ・ 品質アーキテクト 目標人材像 環境連携 BigClouT (日欧ビックデータ・クラウド・IoT融合基盤)JMOOC (オンライン大学講座) オンライン全国展開 実施拠点 WASEDA NEO (コレド日本橋内) 社会人教育プログラム スマートエスイー SmartSE IoT・ビッグデータ・AI × ビジネス IoT・クラウド、ビッ グデータ、人工知 能を活用し、高セ キュリティかつプラ イバシを考慮した スマートシステム &サービスを開発 運用し、技術領域 や分野を超え価値 創造をグローバル にリード可能な実 践的人材の育成と 全国展開 IoT・クラウド、ビッ グデータ、人工知 能を活用し、高セ キュリティかつプラ イバシを考慮した スマートシステム &サービスを開発 運用し、技術領域 や分野を超え価値 創造をグローバル にリード可能な実 践的人材の育成と 全国展開