高信頼化技術適用事例設計工程におけ …...2014/06/24 · ds ds ds ds

Copyright © 2014 NTT DATA Corporation

2014年6月24日株式会社ＮＴＴデータ技術開発本部ソフトウェア工学推進センタセンタ長冨安寛

高信頼化技術適用事例設計工程におけるTERASOLUNA DSの適用

1Copyright © 2014 NTT DATA Corporation

概要

• システム開発における設計書品質とレビュー

• 設計書間の整合性を維持

• 設計書の整合性を機械的に確認できるツール「TERASOLUNA DS」

• 開発経緯と適用事例、効果


アジェンダ

1. システム開発における設計書の重要性－設計書と下流工程との関係

2. 設計品質低下の原因－労働集約型作業

3. 整合性を機械的に確保する－労働集約型作業から知的集約型作業へ

4. 要素技術－文書解析技術、スキーマレスDB

5.効果－事例紹介

6. 新たな課題への挑戦－設計書の自動生成／自動修正

ソースコード解析技術との融合

Copyright © 2014 NTT DATA Corporation 3

１．システム開発における設計書の重要性

ポイント：1. システム設計では段階的に詳細化されていく2. 上流の誤りが放置されると、下流で増幅される

後工程で直すのは多大なコストがかかる（2工程すり抜けると4.4倍のコストが必要）3. 設計不具合はテスト工程で発覚し、これがプロジェクトの遅延／予算超過を招く


システム開発と段階的詳細化

要件定義

設計

製造

テスト

要件を満たすための実現方法を段階的に詳細化記述量も段階的に増大

記述される情報と量

• 要件定義書

• 外部設計書• 内部設計書

• プログラム• 設定ファイル

• テスト項目• テストデータ• テスト証跡• バグ一覧

工程


設計情報の修正工数

要件定義

外部設計

内部設計工程

プログラム製造

記述量

上流工程で不具合を修正することが重要

修正工数比率

後工程にすり抜けるほど修正工数は増大詳細設計：結合テスト＝ 1.00：4.44 （※１）

（※１）「マルチベンダ情報システム開発における障害修正工数の要因分析」http://www.empirical.jp/paperdb/papers/archive/151/151.pdf


設計品質の低下が招くこと

テスト工程で問題発覚コスト超過／納期遅延

結合テストで異常終了多発

エラーメッセージから該当プログラムを特定できず

テスト資材が足りない

正しい情報はどこ？

要件定義

設計

製造

テスト


２．設計品質低下の原因

ポイント：１．「分散開発」「納期優先」により、設計書間の整合性を維持することが難しくなっている２．現状、設計書の品質確保は人手に頼っているが、人間の能力を超えてしまっている


コーディングテスト

労働集約によるソフトウェア開発

従来のソフトウェア開発は労働集約的に作業を実施

設計

大量ドキュメントを作成要員を大量確保して作業

設計書

チェック対象プログラム量の増加


問題意識

複数チーム／拠点間で作成された設計書間で不整合が多発

設計

チームA

チームB

チームC

全体を通してみると不整合だらけ複数チームで並行設計


設計書間の不整合

設計書の不整合例

テーブル名：Ａ- 列 b 数値型- 列 c 文字列型- 列 e 数値型

テーブル定義書処理定義書

・処理名：ＰテーブルＡのd列にステータスを格納する

ＤＢプログラム

存在しない列への代入処理


設計書の品質は後工程になって顕在化

不整合が残存したままコーディング・テストと進み問題プロジェクト化

製造テスト

設計書プログラム

設計書通りコーディング

多数のバグ

チームA

チームB

チームC

問題化


保守工程における設計書品質

設計書間の不整合は開発フェーズ後半～保守フェーズでも発生

開発フェーズでは大量要員が残っているためメンテナンスが可能

保守フェーズでは要員が削減されメンテナンスが困難に

システムに直接影響するプログラムが優先される

設計書

プログラム

設計書のメンテナンスは後回しと…

開発保守・更改


多くのプロジェクトでは実際に設計書は修正されない時間経過と共に陳腐化が進んでいく

保守作業におけるドキュメントの修正度

完全に修正している[20.7%]

[n=371]

設計ドキュメントに関する課題

※経済産業省, JUAS, “ユーザ企業ソフトウェアメトリックス調査2011”, pp223, 2011

約80%のプロジェクトで設計書の品質低下が発生


設計書を修正しなくても「すぐには困らない」

なぜ設計書は修正されないか？

プログラム

修正結果の正しさを確認できる？

＜プログラムと設計書の修正に関する比較＞

動作結果により確認可能

目視でしか確認できない

設計書

業務に支障がでるすぐには困らない修正しないとどうなる？

テスト工程でバグをなおす「もぐらたたき」になる


なぜ設計書は修正されないか？（続き）

品質29%

コスト24%

プロジェクト最優先事項

※引用：経済産業省, JUAS, “ソフトウェアメトリックス調査”, pp68, 2012

設計書修正は最小限としプログラム製造/テスト実施を優先


開発規模が人間の能力を超えている

大規模システム開発の設計書量は人手によるレビュー能力を超えている

要件定義

外部設計

内部設計工程

プログラム製造

記述量

17万ファイル２Ｍステップ

4万ファイル40万ページ

設計書

プログラム


３．整合性を機械的に確保する

ポイント：１．定型的なレビュー観点は、機械化可能である２．機械化可能な領域３．チェックルールの具体例


不整合箇所の摘出方法（従来）

労働集約的にレビューを実施

多人数、並行で設計設計内容をチェック

修正箇所確認

（擦り合わせ）作成・修正完成・維持

影響範囲を調査／修正

影響範囲

変更箇所

不整合

複数回実施問題

記述票


（擦り合わせ）

多人数、並行で設計設計内容をチェック

修正箇所確認影響範囲を調査／修正

TERASOLUNA DSのコンセプト

形式レビューを自動化品質向上・コスト削減

作成・修正完成・維持

影響範囲

変更箇所

不整合

エラーレポート


TERASOLUNA DS 概要

設計情報間の整合性や影響分析を支援設計品質向上と効率化を実現するツール


想定効果：バグ件数の削減

設計製造テスト

処理定義書

SQL定義書

TERASOLUNA DS

エンティティ定義書

処理定義書

SQL定義書


プログラム

DSで不具合検知、修正 → 高品質な設計書設計起因バグ数の削減

• 結合テストで発見されるバグの約50%は「設計書の不具合」に起因（弊社内サンプル調査結果）

修正

設計品質の向上による結合テスト工程摘出バグ件数の削減

コーディング

テスト

0

50

100

150

DS未導入 DS導入

摘出バグ数

♡


TERASOLUNA DS機能概要

整合性チェック影響調査効率化

設計書ＤＢ

問題記述表整合性チェック

レポート

セルフチェック

全文検索

ＣＲＵＤ

設計書内の情報をデータベースに格納し整合性チェックと影響調査効率化を実現

取込


TERASOLUNA DSの機能イメージ

＜整合性チェックレポート＞

必須項目が空欄

一覧に存在しているものが定義書の方にない

エンティティ名が重複



＜セルフチェック＞

オレンジ部分がエラー発生箇所



＜全文検索＞

検索画面

検索結果画面

ファイルの種類が選択できる

・ファイル名・更新日時・格納先



＜ＣＲＵＤ＞

SYSTEMID C R U D C R U D C R U D C R U D C R U D C R U D C R U D C R U D

1 AAA 3 5 4 0 C R U R U C R U C R U R2 AAA 3 5 4 0 C R U R U C R U C R U R3 AAA 3 2 2 0 C R U C C R U4 AAA 3 2 0 0 C R C C R5 AAA 3 2 0 0 C R C C R6 AAA 3 2 0 0 C R C C R7 AAA 3 2 4 0 C U R U C U C U R8 AAA 3 0 0 0 C C C9 BBB 3 0 0 0 C C C10 BBB 3 0 0 0 C C C11 BBB 1 1 1 0 C R U12 BBB 1 1 1 0 C R U13 BBB 1 0 0 0 C14 BBB 1 0 0 0 C15 BBB 1 0 0 0 C16 BBB 1 0 0 0 C17 BBB 1 0 1 0 C U18 BBB 1 0 0 0 C19 BBB 1 0 0 0 C

PGMID PG1 PG2

5 6 7

SYSTEMID AAA AAA AAA BBB BBB

No 1 2 3 4BBB BBB

名称PG3 PG1 PG2 PG3 PG4

NoTABLE CRUD回数 CRUD CRUD CRUD

名称

CRUD一覧

CRUD CRUD CRUD CRUD

IDA01A02A03A04A05A06A07A08B01B02B03B04B05B06B07

B11

B08B09B10


TERASOLUNA DSにおける整合性チェック

”知的集約型作業”に注力できるよう労働集約型作業を自動化

機能間・設計間で整合性がとれているか？

形式レビュー

有識者レビュー

TERASOLUNA DSの対象範囲

設計がそもそも正しいか？

知識集約型

労働集約型


TERASOLUNA DSの整合性チェック範囲

チェック対象

チェック対象外

設計書や規約など具体化された情報

有識者の知見などの情報

設計規約他設計書設計書

チェック可能

有識者設計書

チェック困難

業務要件ノウハウ

ＸＸ

表形式で記述されたもの

ＸＸ

フォーマットが正しいか

整合性がとれているか

文書や図で表現されているもの

1.1 顧客検索処理(1)画面からの入力を

変数Formへ格納(2) Formを入力チェッ

ク関数によりチェック(3) チェック結果がFalseの場合、エラー画面へ遷移する(4) チェック結果が

文章で記述されたもの

画面キャプチャレイアウト図

チェック困難

設計書

チェック対象となる情報チェック可能な表現形式


整合性チェックルールの整備

品質向上につながるチェックルールを整備

(1)開発標準に含まれている設計書レビュー観点→ 199ルールを設定

(2)プロジェクトに蓄積されているレビューノウハウ→ 各プロジェクト独自設定

(3)結合試験時にバグとなるインタフェース情報→ 138ルールを設定


整合性チェック（結合試験時にバグとなるインタフェース情報）の例

整合性チェックの例

処理設計書

テーブル定義書

テーブル名

「処理設計書」の処理対象が「テーブル定義書」と整合が取れている

かをチェック


４．要素技術

ポイント：１．「非定型データ処理基盤」を構築２．設計書様式の標準化３．「エンリッチ」と「NoSQLデータベース」が重要な技術


「非構造化データ活用基盤」整備の構想

NoSQL DB

データ分析(BI/BA)技術

大規模分散処理NoSQL技術

自然言語処理技術

エンリッチエンジン

検索・分析AP

非構造化データ活用基盤

「非構造化データ活用基盤」とは：以下の特徴を持つシステムを支える、柔軟で拡張性に優れたデータ管理基盤• テキスト文書などの非定型データに対し、データの意味を踏まえた検索や分析を可能とする• データの追加／変更に素早く対応できる


TERASOLUNA DS機能要素

設計書

管理情報

ソースコード

レビュー用設計書

・・・

自動修正済み設計書

設計品質評価

運用支援

取り込み設定活用設定状況確認

非構造データ活用基盤上に設計書処理機能を実装

MarkLogic Server

設計書取り込み設計書活用


設計書フォーマットの標準化

表形式（Microsoft Excel）設計書「標準様式」を定義

表形式の設計書イメージ

標準で46種類の設計様式を定義全社で共有／再利用


半構造化データ、非構造化データを検索・集計する仕組み

構造を定義する技術

RDBMSやスキーマ記述言語など汎用的な技術・製品が存在

エンリッチ形態素解析＆意味類推技術

厳密・明示的に構造が定義されていないデータの

構造を推定する

構造化されていないデータを構造化する

構造を推定する技術構造を付与する技術

構造化データ半構造化データ非構造化データ

設計書は「半構造化データ」意味解釈を行うための技術開発が必要

構造が厳密に定義されている

構造が定義されていない

構造の一部が定義されている


「エンリッチ」とは

データの意味を解釈し、データに意味情報を付加する技術

表データ

取得テーブル

テーブル名項目名

顧客顧客コード

商品商品コード

<データ><テーブル名>顧客</テーブル名><項目名>顧客コード</項目名>

</データ><データ>

<テーブル名>商品</テーブル名><項目名>商品コード</項目名>

</データ>

特定サイトでブラウザからファイルをアップロードすると完了後の画面で一部文字化けが発生する場合がある。

電源起動時、まれにUIMカードを認識しない場合がある。またSDカードを認識しないときは、端子部分を乾いた綿棒などで拭いてください。

<条件>電源起動</条件>時、まれに<症状>UIMカードを認識しない</症状>場合がある。また<症状><周辺機器>SDカード</周辺機器>を認識しない</症状>ときは、<対応策>端子部分を乾いた綿棒などで拭い</対応策>てください。

用語辞書表記

ルール

エンリッチ済みデータ

テキストデータエンリッチ


設計書のエンリッチ例

設計書Microsoft Excel形式

エンリッチ後データXML形式


NoSQLデータベースとは

ＮｏＳＱＬデータベースではデータベーススキーマの事前定義が不要

※図はRDBで考えた場合のイメージ

RDB

ID 名称住所代表者名担当者001 NTTデータ東京都江東区光石 NULL002 NTTデータアイ NULL 佐藤斉藤… … … …

データ構造（テーブルの構成・スキーマ）を決定DBに対してテーブル定義を行っておく

テーブルのスキーマにあわせてデータを格納する

ID 名称住所代表者名担当者

NoSQL（XMLDB）

データ格納時にデータ構造を自動的に解析しDBに格納

事前のテーブル定義は不要

ID 名称住所代表者名担当者001 NTTデータ東京都江東区光石002 NTTデータアイ佐藤斉藤… … … …

データ構造の決定データの格納

データの格納

<個人加盟店 ID = “001”>

<名称>NTTデータ<名称>

<住所>東京都江東区</住所>

<代表者名>光石</代表者名>

</個人加盟店>

<個人加盟店 ID = “002”>

<名称>NTTデータアイ<名称>

<代表者名>佐藤</代表者名>

<担当者名>斉藤</担当者名>

</個人加盟店>

データ構造（XML構造）を決定事前のテーブル定義は不要

データ構造の決定


データ変更対応の違い

RDB

XMLDB

カラムの追加既存テーブルの再設計

タグの追加

既存ＡＰの修正は不要

<doc><a></a>

</doc>

テーブルの追加

ＮｏＳＱＬデータベースではアプリケーション影響範囲を局所化可能

該当テーブルにアクセスしている全ＡＰの修正が必要

<doc><a></a>

</doc>

<doc><a></a>

</doc>

<doc><a></a>

</doc>

<doc><a></a>

</doc>

<doc><a></a>

</doc>タグ<b>を含むデータを追加

<doc><a></a><b></b>

</doc>

AP AP AP AP AP AP

AP APタグ<a>にアクセスタグ<a>にアクセス

タグ<b>追加の影響を受けない


NoSQLデータベースの効果

ID テーブル名カラム名カラム属性001 ・・・

… … … …

RDB

NoSQL

ID 処理名項目名処理内容001 登録処理・・・… … … …

テーブル定義書テーブル

処理定義書テーブル

A, B

AP

APクエリ

<テーブル定義書 ID = “001”>

<テーブル名>ＴＢＬ</テーブル名>

<項目名>Ａ</項目名>

<項目属性>数値</項目属性>

</ テーブル定義書 >

<処理定義書 ID=“001”>

<処理名>PROC</処理名>

<項目名>Ａ</項目名>

＜処理内容>・・・</処理内容>

</処理定義書>

格納ID インタフェース名種別項目名項目属性001 登録Ｉ／Ｆ002 … … …… … … …

<IF定義書 ID=“IF01”>

<インタフェース名>ＩＦ</イン

タフェース名>

<項目名>B</項目名>

</インタフェース名>

追加データも同一クエリで検索可能

テーブル定義書

テーブル名項目名項目属性

処理名項目名処理内容

処理定義書

インタフェース名項目名項目属性

Ｉ／Ｆ仕様書

追加

Ａ

B

Ｉ／Ｆ仕様書テーブル

追加テーブルに対してクエリ修正が必要

ＮｏＳＱＬデータベースでは設計様式の追加・変更対応が容易になる

テーブル定義書XML 処理定義書XML I/F仕様書XML


５．効果

ポイント：実プロジェクトによる効果確認

－クレジット系基幹システム更改－銀行系CRMシステム更改


効果の目論見

設計製造・テスト

製造～テスト工程における摘出バグ数を削減全体工数を削減

DS

適用

DS

未適用

摘出バグ数

DS

適用

DS

未適用

設計品質向上によるテスト時の摘出バグ数減• 設計工程のバグ数増• 製造・テスト工程のバグ数減

摘出バグ数

工程

50%削減

工数

システム品質向上による全体工数減• 設計工程における修正工数増• 製造・テスト工程における修正工数減

設計製造・テスト

工程

必要工数

DS未適用

DS適用


実案件における効果確認

大量設計書間の整合性維持、品質向上及び調査工数削減効果を確認

案件効果

銀行系CRMシステム更改

テスト時の摘出バグ密度削減• 設計書の品質向上により、テスト工程におけ

るバグ摘出密度を従来比45%削減

クレジット系基幹システム更改

大量設計書間の整合性維持• データ辞書との整合性維持

データ辞書(10,000項目)と関連設計書(18,000本)の整合性をチェック、不整合0件を達成


課題設計起因の不具合すり抜けで発生するバグの削減

適用事例１金融系システム更改

設計


V1.0


V2.0

変更発生

投入

自動生成ツール

自動生成

プログラム

製造テスト

DB自動生成

プログラムとＤＢ間で不整合発生

エンティティ定義書の変更情報投入漏れ発生


TERASOLUNA DSにより設計情報の不整合を設計工程で検知

適用事例１金融系システム更改（続き）

設計

エンティティ定義書V1.0

エンティティ定義書V2.0

変更発生

投入

自動生成ツール

自動生成

プログラム

製造テスト

DB自動生成

プログラムとＤＢ間の整合性を担保

TERASOLUNA DSによる整合性チェック

修正



＜結合テストバグ検出密度の比較＞

※比較した案件は、同じオフショア会社が開発を実施した結果であり、開発規模、アーキテクチャなどは異なる

適用事例１金融系システム更改(続き)

適用効果設計起因の不具合すり抜けで発生するバグの防止

TERASOLUNA DS導入により結合テストにおけるバグ密度45％の削減を確認

0

0.5

1

1.5

2

2.5

DS未適用 DS適用

バグ摘出密度(

件／K

steps

）

削減


課題:並行して更新される設計書間の整合性

適用事例２クレジット系基幹システム更改

約18,000本の設計書

データ辞書

約10,000項目（各項目ごとに4個の属性）

Ａ社（お客様）

弊社（3チーム）

並行更新

各設計書

データ辞書

Ver1.0 Ｖer1.1

設計書A Ver1.0

設計書C Ver1.0

並行更新のイメージ

Ｖｅｒ1.2

設計書Ｂ Ver1.0

Ver1.1

Ver1.2Ｖｅｒ1.1

Ｖｅｒ1.3

Ｖｅｒ1.1

Ver1.2

データ辞書連携日


TERASOLUNA DS

TERASOLUNA DSにより、データ辞書と各設計書の整合性をチェック


データ辞書

お客様

各設計書

設計書設計書

データ辞書

ＣA

B

整合性をチェック

不整合箇所の確認・修正



設計工程完了時点で不整合件数０件を実現

0

5000

10000

15000

20000

25000

30000

35000

40000

1週目 2週目 3週目 4週目 5週目

データ辞書連携日

データ辞書更新中のためエラーが多発

データ辞書が最新化されエラー解消


データ辞書に登録されていないものを修正

エラー件数


６．新たな課題への挑戦

ポイント：１．設計書チェック範囲の拡大２．設計書自動生成／自動修正３．適用範囲をソースコードへ拡大（TERASOLUNA DS ACA拡張）４．ルール作成機能の高度化


実施事項

TERASOLUNA DS 自動チェック範囲

自動チェック範囲の拡大

TERASOLUNA DS自動チェック範囲を拡大すり抜けバグを削減する

チェック可

明文化されている

設計規約

設計書

ＸＸ

表形式/フロー図で記述

ＸＸ

設計様式／規約の改善

ＸＸ

他設計書設計様式を変更



ク関数によりチェック

解析機能の強化1.1 顧客検索処理(1)画面からの入力を


ク関数によりチェック自然文解析他設計書

処理名=顧客検索

FY2013試行結果・自動化によりすり抜けバグを3分の1に削減可能

全社標準様式に反映

チェック不可

明文化されていない

専門家

業務要件ノウハウ



ク関数によりチェック(3) チェック結果がFalseの場合、エラー画面へ遷移する(4) チェック結果が

TERASOLUNA DS導入案件で ”すり抜けバグ”が多発・文章で記述され、DS自動チェック不可

“リスク価格項目に12桁の9を設定する”

「リスク価格項目」は10桁の数値

処理定義書インタフェース定義書

不整合


設計書自動生成／修正機能

“設計書自動生成機能”と”設計書自動修正機能”により設計書作成／修正工数を削減

DS

一覧定義書

一覧定義書 DS

誤り一覧修正候補確認自動修正

不整合の30-80%は「表記ゆれ」テキスト処理技術で自動修正可能（用語辞書、編集距離計算等）

「ユーザテーブル」が”DB定義書”に存在しない

”利用者テーブル”に修正しますか？Y/n

エラー118件中表記ゆれ98件

修正結果

任意の時点に戻せる

問題記述表

元設計書選択条件指定自動生成

設計工程の工数５％削減・各種一覧（画面一覧／テーブル一覧）

・管理用メトリクス（FP、スコープ、テスト消化状況 etc.)

設計書自動修正機能

設計書自動生成機能


ソースコードチェック機能（ACA機能）概要

凡例

「設計書陳腐化防止」と「テスト工数の削減」を目的とした“設計書-ソース” と ”ソース-テスト環境”の整合性チェック

ソースコードテスト環境

オープン系（Java等）

ホスト系（COBOL等）

設計書

②設計書とソースコード間の整合性

①設計書の整合性③ソースコード

の整合性④ソースコードとシステム間の

整合性

コンパイラや統合開発環境によるチェック

TERASOLUNA DS ACA機能対象範囲自動化範囲手作業範囲

有識者のレビューによる同期

テスト環境で整合性を確認

TERASOLUNA DS構成管理・リリース管理の仕組みで同

期


ソースコードチェック（ACA）機能試行結果

# 対象言語目的方法実プロジェクトにおける試行結果

1 COBOL テスト工数削減

結合テストで異常終了となるバグを事前摘出

・事前摘出バグ数： 277件・削減工数：約７人月

単体テスト完了直前ソースを解析(対象数：4,485本)

2 シェルスクリプト

調査工数削減

プログラム間の呼出関係を可視化

・工数削減率：70～80%

COBOL版 ACA と組み合わせて実施結合試験中ソースを解析（対象数： COBOL 3,205本、シェル 5,259本）

3 Java, JSP 調査工数削減

(設計書-ソース間の乖離調査)

設計書とソースコード間の整合性をチェック

・摘出不整合数：3,850件・工数削減率：70～80%

+潜在バグ1,800件摘出（機能追加時に顕在化）サービス開始後の設計書／ソースを解析(※対象数：設計書：300本、ソース1,800本)

4 JavaScript 影響範囲調査工数削減

プログラム間の呼出関係を可視化

・工数削減率：23%

サービス開始後のソースを解析（対象数： 360本）

工数削減を目的とした４種類のツールを試作実プロジェクトにおいて有効性を確認


前バージョンと比べ平均10分の１の工数で設定可能

※ 設計書解析設定画面の例

ルール作成機能の高度化

簡単に設定を追加できるＧＵＩツールを提供


まとめ

• 高品質なシステムを開発するためには、設計書間の整合性維持が非常に重要

• 設計品質低下の要因は「労働集約型」で作業を行っていることである

• 整合性チェックを機械的に確保することで、労働集約型作業から解放され「知識集約型」作業へ集中できる

• 実プロジェクトにおいて、システム全体の品質向上につながることが確認できている

高信頼化技術適用事例 設計工程におけ …...2014/06/24 · ds ds ds ds

Documents

高信頼化技術適用事例設計工程におけ …...2014/06/24 · ds ds ds ds