第1回 ソフトウェア工学とは - sic.shibaura-it.ac.jptsnaka/lecture/se1/第13回...

ソフトウェア工学１第13回 品質マネジメント／ソフトウェア工学の最新動向

2017年7月18日中島

1

講義内容

• 品質マネジメント

品質マネジメントの狙い

品質計画

品質評価と対策

• ソフトウェア工学の最新動向

– 製品とソフトウェアの傾向

– ソフトウェア工学の方向性

• モデルベース

• つくらない技術

• 応用分野別エンジニアリング

2

品質マネジメントの狙い:プロセスアプローチ

■ ISO9000 品質マネジメントシステム

プロセスアプローチとは：

開発する製品の品質向上を、最終工程における検査にだけ頼るのではなく、開発に関わる各プロセスの品質を上げることで、結果として製品品質を向上するアプローチ

良い製品は良いプロセスから生まれる

製品

最後になって品質を上げようとしても無理

ﾌﾟﾛｾｽ1 ﾌﾟﾛｾｽ2 ﾌﾟﾛｾｽn

プロセスを制御し、改善することで品質を達成する

開発プロセス

品質マネジメントの狙い:計画・測定・制御

各段階の生産物／プロセスが品質目標値を達成しているかどうかをﾁｪｯｸ

製品の品質目標を達成するために，開発各段階の品質活動と目標を計画し，測定し，制御する

品質計画

製品の品質目標 製品開発

品質保証

要求分析

設計ｺｰﾃﾞｨﾝｸﾞ ﾃｽﾄ

ﾁｪｯｸ ﾁｪｯｸ ﾁｪｯｸ ﾁｪｯｸ

品質指標値の測定管理活動（制御）

各段階の生産物を品質目標を意識して開発

ﾚﾋﾞｭｰ ﾚﾋﾞｭｰ ﾚﾋﾞｭｰ

4

各段階の品質目標

各段階の品質活動

品質計画書

品質マネジメントの狙い：コスト最適化

欠陥は，早く見つけるほど少ない作業量で処置できる

要求 設計 ｺｰﾃﾞｨﾝｸﾞ

ﾃｽﾄ 出荷後

0.1 0.51

2

20修正コスト比（ｺｰﾃﾞｨﾝｸﾞを１）

後工程での欠陥検出は，リワークコストが高い

5

品質マネジメントの狙い：コスト最適化

要求分析

外部設計

ｺｰﾃﾞｨﾝｸﾞ単体ﾃｽﾄ

内部設計

結合テスト

総合テスト

本来の理想的なコスト

コスト設計で混入欠陥

を少なくする対策

前工程やり直し

工程内やり直し

テストよりレビューで欠陥除去することによるコスト削減

6

開発コストを理想に近づけるために品質活動を計画する

ソフトウェアの品質をどう見るか

7

ソフトウェアの品質は直接見ることができない

ソフトウェア

(1) 上流の品質の悪さが，そのまま下流に引き継がれる．

(2) 論理的／物理的な構造により品質の良さ／悪さが偏る．

特徴を理解すると，品質が見えてくる．

品質面のソフトウェアの特徴１

上流の品質の悪さがそのまま下位に引き継がれる

8

システム設計

S/W要求分析

S/W方式設計

S/W詳細設計

ｺｰﾃﾞｨﾝｸﾞ

S/W単体テスト

S/W結合テスト

S/W総合テスト

システムテスト

検知欠陥

混入欠陥

流出欠陥

プロセスの悪さ プロセスの悪さ

例えば，ソフトウェア外注範囲がここだったとすると・・・

品質面から見たソフトウェアの特徴２

論理的／物理的な構造により品質の良さ／悪さが偏る

難易度が元々高いインタフェースが複雑

担当開発チームの質が悪い

８０％の欠陥は２０％のモジュールに集中する

パレートの法則

システム

9

悪

悪

品質評価と対策

現状把握： 考えてみよう！

10

1. 現状を把握し，このままだと将来どうなるかを判断する．

2. このままではダメな場合，悪いところを特定し、追加レビュー，追加テスト，（最悪）作り直しなどの対策を打つ．

あるソフトウェアをテストしたら30件の不具合が検出された．品質は良いと言ってよいのか悪いのか：

• 30件出たという事実のとらえ方：• 30件も出た → もう出ない• 30件しか出ない → もっと出るはず

• 品質状況を判断するには，どんな情報が足りないか？

品質評価と対策の技法

(1) 過去の実績から，将来の事象の確からしさを予測する

(2) トレンドを見て，将来を予測する

(3) 悪いプログラム部分／プロセスを特定する

11

過去の実績データを使うには：

• 過去のプロジェクトは，開発したプログラムの規模が違う→ 単純に比較できない

• 「正規化」してそろえる（規模に相当するもので，割る）例） プログラム規模(kL), ドキュメント量（ページ）

テスト密度（テストケース数／kL)レビュー密度（レビュー工数／ページ）

品質評価の技法１： 相関推定法

(1) 過去の実績から，将来の事象の確からしさを予測する

ソフトウェア外注納品時静的解析の警告件数 30件以上

総合テスト検出欠陥密度 0.2件/kL以上

例）

12

出荷後欠陥密度が0.04件/KL以上

確からしさ95％

出荷後重大不具合数が1件以上

確からしさ75％

過去のプロジェクト： a → b現在のプロジェクト： a’ → ?

現在段階で測定可能な指標A

知りたい将来の指標B

品質評価の技法１： 相関推定法

(1) 過去の実績から，将来の事象の確からしさを予測する

過去のプロジェクト： a → b現在のプロジェクト： a’ → ?

現在段階で測定可能な指標A

知りたい将来の指標B

P(Rb）

P(Ra）

確からしさ（尤度）→ 条件付確率P(Rb|Ra）

A（現段階）

B（将来）

相関係数による関係性の判定

→ １次式

P(b in Rb）

P(b in Ra）

過去のプロジェクトの実績データ

13

A（現段階）

B（将来）

品質評価の技法： 外挿法

(2) トレンドを見て，将来を予測する

フェーズ間検出欠陥成長曲線フェーズ内欠陥成長曲線

D: 検

出欠陥類積数

実測値

予測値（成長曲線モデル）

K: 欠陥数の収束点

目標発見件数

テスト終了日予測

テスト終了基準

t: 時間（またはテストケー数）

ゴンペルツ曲線

D=Kabt

K,a,b を推定

要求分析

方式設計

詳細設計

ｺｰﾃﾞｨﾝｸﾞ

単体ﾃｽﾄ

結合ﾃｽﾄ

総合ﾃｽﾄ

レイリーモデル

14

開発のこれまでの傾向から，将来を予測し，品質判断をする

出荷基準

テストの終了を判断する 出荷可否を判断する

d: 検

出欠陥数

d=K(tm-2・te-(1/2tm )t )2 2

品質評価の技法： ゾーン分析法

(3) テスト作業（作業量）とテスト結果（欠陥数）から判断する

テスト作業密度(テスト項目数/kL)

目標値

目標値

評価単位（コンポーネント，モジュールなど） 15

過去の類似の良好なプロジェクトの値を使う

±x%適正領域

品質は 悪い

（テストを続ければ欠陥がまだ出ると推定）

→原因究明と対策，

必要に応じて作り直し

品質は 不定（テストを続けた場合欠陥が出る

か出ないか判断できない）

→付加的にテスト/レビューを実施し判断

品質は 良好

（残存欠陥は少ないと推定，

意味のないテストしていないか確認）

品質は 不定

（テストを続けた場合欠陥が出るか出ないか判断できない）

→テスト/レビューの継続実施

散布図を使って，悪い部分を見つける

まとめ

• 品質マネジメントは，製品の品質目標を、開発各段階を計画，測定，制御することで達成する．

• 品質マネジメントは，

– レビュー、テスト、監査を手段とする．

– 評価は，プロダクト指標だけでなく，プロセス指標を使う．

– 過去の実績を使う，トレンドをみる.– 悪いところにフォーカスする.

16

講義内容

• 品質マネジメント

品質マネジメントの狙い

品質計画

品質評価と対策

• ソフトウェア工学の最新動向

– 製品とソフトウェアの傾向

– ソフトウェア工学の方向性

• モデルベース

• つくらない技術

• 応用分野別エンジニアリング

17

製品とソフトウェアの傾向

付加価値創生の源泉： ハードウェアからソフトウェアへ

18

（１）ソフトウェアの重要性が増大

（２）ソフトウェアの開発規模が増大

開発のコストと期間が増大

社会インフラを支える： システム障害→インパクト大

（３）市場競争が激しい

市場ニーズに応える製品を、早く安く

プログラムを作るより、 自動生成する既存のものを使う

品質がますます重要に

今後の開発スタイルのトレンド

画像処理

通信

技術開発

調達

良いものは買う

付加価値のあるところは

作る・・・

品質高く、早く、組み立てることが重要

企画・設計・構築・評価プロジェクトマネジメント

組み立て

キー技術 そうでない技術

システム製品

19

他のシステム

他のシステム

他のシステムと相互運用する

ソフトウェア工学の方向性

• モデルベース （仕様レベルで開発・テスト）

– モデリング言語とサポート環境

– プログラム自動生成

– 自動検証・テスト

• つくらない技術

– 長持ちさせる： アーキテクチャ設計・評価，トレーサビリティ

– 系統的再利用：ソフトウェア・プロダクトライン

– つなげて使う： つなげるための、設計とテストと品質保証

• 応用分野別エンジニアリング

– Webサービスの開発技術

– M2M/IoTの開発技術20

モデルベース開発

モデル： システムの仕様やふるまいをある視点から抽象的に記述したもの

21

• 仕様の表現・定義 「実行可能な仕様書」

• モデル記述に基づく検証

• 自動 コード生成

• テストケース生成

• 汎用目的： UML• 制御系特化： Matlab/Simulink

モデルベース開発：モデルを使った開発の効率化・自動化

UML (Unified Modeling Language)

22

ステートマシン図

タクシー

担当エリア

位置報告

ハイヤー

賃走車車NO状態位置

乗車履歴出発地到着地出発時間到着時間客種

～を持つ配車センタ 呼出１

了承配車開始

営業中

流し中 迎客中

確定

賃走中

賃走中指定賃走終了

客なし

呼出

配車センタ

オブジェクトのふるまい

クラス図

シーケンス図

オブジェクト間のやりとり

（システム機能の実現）オブジェクトの静的構造

汎用目的のモデル

UMLベースのシミュレーション

23

対象： 鉄鋼圧延プラント監視制御システム目的： 監視画面に対する顧客要求の抽出と妥当性確認

Down Coiler

Tracking Zones

Steel Materials

Finishing Mills

furnace

シミュレーション画面UML

実行可能仕様

中島他：顧客対話時の要求獲得と確認を支援するプロトタイピングツール：ROAD/EE,電子情報通信学会D-I(2002年8月)

UMLを用いたコード自動生成

24

PIM: Platform Independent Model

PSM: Platform Specific Model

ステートマシン図

クラス図

シーケンス図

UMLモデル

Action言語

＋環境依存情報

OS

デバイスドライバ

＋

プラットフォーム依存形式

変換

コード自動生成変換

実行コード

ミドルウェアをうまく使えない⇒ 普及✖

Matlab/Simulink: 制御系向きモデル

25

数値計算ライブラリのついた高機能BASIC

行列計算グラフ表示

Matlab （言語）

Simulink（シミュレータ）

ブロック線図で構成するダイナミックシミュレータ

状態方程式

ソフトウェア工学の方向性

• モデルベース

– モデリング言語とサポート環境

– プログラム自動生成

– 自動検証・テスト

• つくらない技術

– 長持ちさせる： アーキテクチャ設計，評価

– 系統的再利用：ソフトウェア・プロダクトライン

– つなげて使う： つなげるための、設計とテストと品質保証

• 応用分野別エンジニアリング

– Webアプリケーションの開発技術

– M2M/IoTの開発技術26

製品開発の流れ

27

初期製品開発（顧客A向け）

シリーズ開発（顧客ニーズ追随）

機種分岐

XA-0 XA-1 XA-2 XA-3

XB-1 XB-2

市場ニーズの変化テクノロジーの進歩保守コストの増大

YA-0次機種開発

YA-1

XB-3 YB-1

開発

出荷

ﾍﾞｰｽとして利用

仕様取り込み

顧客(分野)A

顧客(分野) B

製品ライフサイクル

要求分析

設計 製造テスト

開発ライフサイクル

工程

企画

ドメインC

ソフトウェア・プロダクトラインアプローチ

28マネジメント

ドメインBドメインA

コア資産開発

使用経験に基づく変更要求

コア資産

製品開発

市場の要求 既存の個別製品仕様 生産制約条件

開発・保守 使用

個別製品

個別の顧客（あるいは顧客セグメント）の要求

統制・支援

ソフトウェア・プロダクトライン

29

状態管理層

制御層

情報層

デバイス層

設計モデル

制御仕様モデル ソースコード

状態遷移表 状態遷移実装

制御フロー 順次実装

制御機能 ソフトウェア部品

エアコンフレームワーク

エアコンフレームワーク要求からソフトウェアコードまでの変換ルール

Motoi Nagamine,Tsuyoshi Nakajima, Noriyoshi Kuno: A Case Study of Applying Software Product Line Engineering to the Air Conditioner Domain, Software Product Line Conference 2016

空調分野での応用

品質要求・評価手法に関する研究

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

機能完全性機能正確性機能適切性

適応性設置性置換性

時間効率性資源効率性容量満足性

共存性相互運用性

適切度認識性習得性運用操作性ユーザエラー防止性

ユーザインタフェース快美性

アクセシビリティ

成熟性可用性障害許容性（耐故障性）回復性

システム／ソフトウェア製品品質

機密性インテグリティ否認防止性責任追跡性真正性

モジュール性再利用性解析性変更性試験性

（製品）品質特性 25010

品質特性と品質測定値を使って，品質要求を記述する．

品質要求 25030: 現在策定中（国際プロジェクトエディタ）

ソフトウェア工学の方向性

• モデルベース

– モデリング言語とサポート環境

– プログラム自動生成

– 自動検証・テスト

• つくらない技術

– 長持ちさせる： アーキテクチャ設計，評価

– 系統的再利用：ソフトウェア・プロダクトライン

– つなげて使う： つなげるための、設計とテストと品質保証

• 応用分野別エンジニアリング

– Webアプリケーションの開発技術

– M2M/IoTの開発技術31

新テクノロジーからソフトウェアエンジニアリング

32

新しいテクノロジー

革新的アプリ フレームワーク化

エンジニアリング技術の発展

多くの商用製品新しいテクノロジー登場後，エンジニ

アリング技術が整備されていく

・ オブジェクト指向・ Web・ IoT

無線

注目すべき技術： M2M/IoT

• M2M： Machine to Machine• IoT: Internet of Things

– 多数のセンサや機器をインターネットに直接接続

– 人手を介さずに、様々なサービスを提供する

– センサ、通信、情報処理に関する、横断的なシステム技術

センサ

アクチュエータ

M2Mゲートウェイ

クラウド／サーバ

インターネットアプリケーション

携帯端末／PC

あらゆる「もの」がデータ化

33

実世界 ビックデータ・AI

データ収集

制御

情報閲覧

M2M/IoTの紹介動画

M2Mの応用分野は広い

• スマートエネルギー

• ホームオートメーション

• 施設の管理（駐車場、ビル）

• 小売り

• 農業（ビニールハウス管理、害獣対策）

• 防災

• 福祉（老人医療センター）

• 交通、輸送機

研究テーマ：車内見守りシステム（１５年度～）

置き去り（熱中症危険性）や車上荒らしを判定

インターネット

駐車場

警備会社

近距離無線通信

駐車場警備センタ

ユーザの車

温湿度センサ人感センサ

GPS・・・

スマホ

サーバ

リスク判定＋制御ルールユーザ

通知

ユーザの個人情報

監視データ

駐車場情報

制御

研究２熱中症判定ロジック

研究１

通信確立とセンサデバイス電源コントロール

研究３M2Mセキュリティ

研究テーマ（16年度～）

• 自転車盗難防止・対策

• 歩きスマホ防止

36

Keisuke Yamazaki and Tsuyoshi Nakajima: Riskinformation provision system on Bicycle parkingLots, 2nd IEEE International Congress on Internetof Things, Honolulu, 2017

卒研導入を目的としたM2M/IoT実習会

M2M研究会の先生

1/23～3/19 全５回（２週おき）

M2M研究会の先生

準備試作： 研究室の在室確認システム

照度センサ＋arduino

＋

Xbee通信

研究室内

シリアル通信

＋ ＋

情報端末からWebアクセス

Web アクセス

クラウド

照度データ

WiFi 通信

点いた／消えた

arduino RaspberryPi