aretan.jp

早稲田大学　名誉教授　東¶

どんどん人がきて教育なんてできない
品質のために標準化しなきゃいけない
NECソフトウェア生産技術研究所
システム品質っていうのは動けばいいってもんじゃない

ICTの進歩により多様化し複雑化している
銀行とか自動車とか重大リスクのあるものも少なくない
こういうものの品質向上は現代社会で最重要課題

重大な欠陥と不適切な対応は企業存続のリスク
高品質な製品の技術開発は技術者の責任
製品の利用は利用者の責任
高品質な製品は世界を制する

アメ車がなぜ日本で売れないのか？
会社だから売れてない訳じゃない
日本に売る気がそもそも無い
日本車もう輸入しないよはおかしい

SQUAREはユーザーにフォーカスした品質ではなく、
広範な意味の品質として捉えている。
使用性・共存性・セキュリティ・正確性・・・

明示的ニーズ・暗黙的ニーズを製品が満足させる度合い（SQUARE25010品質モデル）
品質モデルと品質測定量で定義する

アメリカでは焼き加減を聞かれるが、
フランスでは焼き加減を指示すると怒られる
誇り高いので一番おいしい焼き加減で提供する

内部品質：仕様書などのレビューで測定できる静的な品質
外部品質：システムとしての動作による動的な品質
利用品質：ユーザビリティ・利用時の品質

企業ごとに品質向上技術戦略を確立する
品質要求を明確化し、品質を作り込むためのプロセスを作る

swebok優れた技術開発者
UML優れた技術ツールの選択基準
・・・などの標準仕様

８５年に国際会議に出たらまだフローチャートとかやってる
そこから標準品質モデルを定義しはじめる
９１年にISO9126を発行→ISO14598→SQUAREシリーズ化

Software Product Quality 9126
Software Product Evaluation 14598

ISO 25000Squareシリーズ国際標準の狙い

品質要求分析・定義プロセス→設計・品質設計・開発＆テスト→・・・

標準品質モデルがあれば、わざわざ一からやらなくてすむ
製品の内部及び外部品質の測定　２５０２３
ソステム＆ソフトウェア品質モデル　２５０１０
データ品質の測定　２５０２４
データ品質モデル　２５０１２
利用時の品質の測定　２５０２２
利用時の品質モデル　２５０１０

利用時の品質→利用時の品質要求→外部品質要求仕様→内部品質要求仕様→内部品質→外部品質→
利用者ニーズ→利害関係者ニーズ

利用時の品質モデル（Quality in Use Model）
有効性　有効性
効率性　効率性
満足性　実用性　信用性　快感性　快適性
リスク回避性　経済リスク緩和性　安全リスク　環境リスク
利用状況網羅性　利用状況完全性　柔軟性

ソフトウェア品質モデル
機能性・・・
信頼性・・・
使用性・・・
効率性・・・
保守性・・・
移植性・・・

→JIS X 25010
機能適合性
性能効率性
互換性
使用性
信頼性
セキュリティ
保守性
移植性

データ品質 25012
固有の品質とシステム依存の品質がある
・・・・２５０１０より大量にある

測定できないものは、評価・制御・管理できない
２５０２０　測定参照モデル・手引
２５０２１　品質測定要素
２５０２２　利用時の品質の測定
２５０２３　製品品質の測定
２５０２４　データ品質の測定

資源及び環境がよければ、製品品質プロセスがよい
製品品質プロセスがよければ、製品品質もよい・・・

品質評価プロセス　２５０４０

TS 25011：IT service Quality Model

完全はなく、追い続ける事が必要
国際標準の適用、新技術の適用と改善の継続が成功の鍵

質疑応答
セキュリティというのは機能だがセーフティは機能ではない
セーフティは結果、SQUAREではリスク回避性としてしている

利用時の品質特性・製品の品質特性
実験すればわかるけど、製品ごとにちがう
重要度をランク分けして決定していく
一般解は出せないが、答えを導き出すものとして使えるんじゃないか

MathWorks　次世代システムに求められるソフトウェア検証技術¶

Polyspaceの製品の説明だった。。。
まあ動的解析だけじゃちょっと足りない部分あるから、静的解析もしないといけないよね

シンタックス
セマンティクス
モデル検査
データフロー解析
制御フロー解析
形式手法

コーディング
コードメトリクス
コード証明

ISO26262

楽天トラベルの開発プロセスに関して¶

PDM（プロダクトマネージャー：未来を考える人）２０名
開発エンジニア１００名
QA３０名
新規プロジェクト年間３００

アージェント（即直す）２割
プライオリティ１（１週間）４割
プライオリティ２（１ヶ月）２割

QAプロセス改善について
これまで
課題　起案　レビュー　要件定義
開発設計　テスト設計　テスト　リリース

時代とともに開発は早くなっていくのに、
テストは今まで通りだとどんどん大変になる。
そういうわけで、プロセスを変更しようってなった。

テスト設計をtest specとcase designに分割した
要件定義のタイミングでtestabilityを検証するフェーズを追加
テスト設計も前倒しでやるように、UTちゃんとしようとか

テスト自動化エンジニアというものを置くという取り組みも始めた
ドキュメントを書く、設計にはとても金かかるけど、トータルは抑えられる
さらに、これはリグレッションにも使えるようになる。
これをデベロッパーに渡して、クオリティゲートとしてこれ通ってから渡してね。
商用で動かしてインフラエンジニアにも渡すようにした。

これによってQAの責任範囲が広くなった
UT IT QA Release Operation
デベロッパーが開発に専念できるようになる！

QAの責任と権限
QAの実施可否
　クオリティゲート通ってないとテストしねーよ？
本番リリース可否
　バグあるけどまぁこの程度なら出していいよ？これじゃだめだよ？

QAとdevとpdmの権利を三権分立させて、強くなりすぎないようにしてる。