Microsoft PowerPoint _企画セッション3_配布用.ppt [互換モード]

Loading....

Loading....

Loading....

Loading....

Loading....

全文

(1)

企画セッション

3

品質がもたらすソフトウェアのビジネス的価値

東京証券取引所

arrowhead 開発のユーザ側、ベンダ側双方

のプロジェクトマネージャに聞く

本セッションの主旨と構成

• 主旨: 品質とビジネス価値のつながりを考える。

• 構成

– ご講演

• 東京証券取引所 宇治 浩明 氏

• 富士通 三澤 猛 氏

– ディスカッション

• 会場への質問を含め3件程度

• 進行: 森崎 修司

– 全体進行: 脇谷 直子

本セッションの前提知識

arrowhead: 東証の株式売買システム

IT Japan Award 2010 経済産業大臣賞(グランプリ)受

賞(主催: 日経コンピュータ)

arrowhead開発のプロジェクトマネージャ

– 東証 宇治氏(株式売買システム部長)

– 富士通 三澤氏(保険証券ソリューション事業本部 東

証事業部 プロジェクト統括部長)

2011年9月9日

株式会社東京証券取引所

株式売買システム部長

宇 治 浩 明

株式売買システム

arrowhead

開発事例

品質と

レイテンシーで海外投資マネーを呼び込む>

SQiP2011

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

4

-<プロジェクト概要>

プロジェクトの始動

国際的な市場競争力の強化

海外投資マネーを集める力

市場からの信頼回復

市場環境の変化

高頻度取引(HFT)に対応するべく

取引所間でのスピード競争

システム障害等の経験

プログラムのバグ、リリース・ミス

キャパシティ不足

arrowhead(次世代株式売買システム)の構築

市場を巡る環境変化や、市場の信頼回復のため、

次世代の市場インフラとなるシステム構築が始動

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

5

-<プロジェクト概要>

arrowhead開発の基本コンセプト(コアファクター)

海外視察も踏まえ、arrowhead構築の基本的なコンセプト+定量目標を取りまとめ、提示

拡張性

あらかじめ定めた拡張基準を超えた場合、1週間程度で対応を可能とする。

〔拡張基準(想定)〕

1日、または、分間の注文件数において、

実績ピーク値がシステム限界値の半分の件数を超えた場合

⇒ 過去の1日or分間の最大件数の2倍のキャパシティを常に用意

高速性

注文受付通知のレスポンスを10ミリ秒以下

相場情報配信のレイテンシーを5ミリ秒以下

⇒稼動後実績は平均2ミリ秒

⇒稼動後実績は平均3ミリ秒

柔軟性

多様な商品や取引ルールの追加、変更に短期間で対応可能とする。

⇒機能のパラメータ化、アタッチメント型業務ロジック

信頼性

99.999%以上の可用性の確保を目標

⇒主要な処理サーバ(トレーディングサーバなど)は三重化構成

堅牢性

セカンダリサイト(バックアップセンタ)の構築

広域災害時24時間以内復旧

その他

情報配信機能強化

システム運用堅確化

セキュリティ強化

(2)

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

6

-<プロジェクト概要>

プロジェクト運営方針

チーム内の合意形成

Challenge “10” msec !

高速性と信頼性を両立する、世界一の取引所システムを創る。

上流工程“完璧主義”

<品質管理>

設計書レビューの徹底。問題点へのリアルタイム対応。

要件トレーサビリティの確保。

②“ライフサイクル”コスト・セーブ

<コスト管理>

コスト管理の意識強化。発生ベースの月次管理。

③“デジタル”予実管理

<スケジュール管理等>

進捗、品質、リスクレベルの予定と実績をリアルタイムに

数値評価し、プロジェクトを可視化。

“次世代”育成

<人材育成>

ITで価値を創造できる人材の育成。IT総合力の強化。

“ワイガヤ”民主主義

<コミュニケーション管理>

率直な意見交換。カウンターパートの“人となり”を知る。

⑥“先手必勝”リスク制圧

<リスク管理>

QCDについて予防的・継続的なリスク・モニタリングと

リスク・ヘッジ。

◆プロジェクト管理方針

⑦リニアなスケールアウト

<拡張性>

ハードウェア増設によるリニアな拡張。

ミリセカンド・レスポンス

<高速性>

注文受付10ミリ秒、情報配信5ミリ秒。

⑨Non Stop Market

<信頼性>

稼働率=99.999%。

⑩アタッチメント型業務ロジック

<柔軟性>

高速で普遍的なフレームワークと付け替え可能な業務ロジック。

⑪Simple is Best

<メンテナンス性

主要業務ロジックの簡素化。付帯業務の外出し。

◆システム設計方針

◆スローガン

One Team, One Dream.

世界一のシステムを目指して頑張ろう!

◆会社間をつなぐスローガン

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

7

-東証側協力会社メンバー

約50名

システム

テスト

<プロジェクト概要>

プロジェクトのスケジュール全体像

参加者接続テスト

2006年

2007年

2008年

2006年3月

2006年4月~8月

証券会社のCIO、

実務者ミーティング

計画策定

プロジェクト計画

2006年9月

欧米視察、 マイ

ルストーン公表

市場利用者と基本コンセプト、システム要件、開発投資計画等を協議

結合テスト

製造

▼接続仕様(第0版)説明会

2009年

システム構築

▼接続仕様(第1版)説明会

本番

稼動▼

詳細設計

内部設計

開発ベンダ選定

コンペ

富士通

選定

証券会社との十分なテスト期間を確保

▲▲ ▲

▲CIO

▲ ▲

▲実務者

プレ受入+受入テスト

東証プロパー 約25名

開発体制

富士通メンバー 500名以上(ピーク時)

2010

プロジェクトオフィスに全員集合!

要件定義+外部設計

東証

ベンダ

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

8

-目的

会議体

主催者レベル

頻度

内容

経営層の

対話

プレジデント

レビュー

社長・会長

ほぼ3ヶ月毎

東証・富士通両社の経営トップレベルで

のプロジェクト全体レビューと方針の決定、

確認

ステアリング

コミッティ

関連役員

四半期毎

 システム本部、関連業務部門を含めたプ

ロジェクト全体レビューと方針の決定、確認

CIOレベル

での

進捗・品質

チェック

工程会議

東証側CIO+

ベンダ側担当

役員

1ヶ月毎

 システム本部のプロジェクト全体レビュー

とアクションの決定

品質評価会議

CIO+

プロジェクト

責任者

1ヶ月毎

 当該工程の品質状況や次工程の準備状

況等を評価し、アクションを決定

全社ベース

で 移行・

稼動対応

全体移行

統制本部

専務+全役員

2009年10月

2週間毎

本番移行に向けた準備状況について、

関連業務部門の対応状況も含め、進捗

表・チェックシートに基づき確認

稼動判定会議

社長+全役員

+関連部門

2009年11月

3回

 稼動判定基準に基づき、稼動に向けた

準備・適合性をチェック

 中間判定会議(準備状況)を11月、適合

状況を12月、1月(最終判定)で確認

<プロジェクト概要>

開発ベンダ、社内関連部門との合意形成

経営レベル

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

9

-<プロジェクト概要>

開発ベンダとの合意形成

実務レベル

開発ベンダとの週次ミーティングをテーマ毎に細かく設定し、密なコミュニケーションを継続。

8:30 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 運用・テスト・移行 分科会 T : 運用・テスト・移行チーム F : テスト推進, テストツール, 運転制御, 運用, 移行 共通検討WG (検討案件があれば開催) GPM-C T:マネージャー 東証本館にて 隔週開催 市場監視分科会 (自由検索) T : 市場監視 F : 市場監視 外接分科会 T : 他システム連携チーム F : 外部接続チーム 朝礼 (9:00) 朝会 (9:10) 市場監視 分科会 (画面開発) T : 市場監視 F : 市場監視、クライアント開発 FM/規制分科会 T : 売買監理チーム F : FM/規制チーム 参加者 分科会 T : 参加者 チーム F : 参加者 チーム 情報配信 分科会 T : 情報配信 チーム F : 情報配信 チーム 市場監視 分科会 (共通) T : 市場監視 F : 市場監視 朝会 (9:00) 朝礼 (9:00) 朝会 (9:10) 朝会 (9:00) 朝礼 (9:00) 朝会 (9:10) 朝会 (9:00) 東証 インフラ進捗 T: インフラチーム 富士通 朝礼 (9:00)

朝会 (9:10) チーム間進捗会議 T : 全チーム 朝礼 (9:00) 東証 朝会 (9:00) 朝会 (9:00) 東証 時間

東証 富士通 東証 富士通 富士通

性能WG (隔週実施) T : インフラチーム F : 性能チーム 内部検討 WG (リーダー会終 了後) 朝会 (9:10) 標準化コミッティ T : マネージャー 東証本館にて開催 基盤グループ進捗1 F : インフラ基盤, ネットワー ク, システム運用, 性能 基盤グループ進捗2 F : アプリ基盤, GW基盤, DB/DAM, 性能 お昼休み(11:45 ~ 12:45) 富士通 統合ネット 定例 T : 参加者・情報 配信・他シス連携・ インフラ・運用・テ スト・移行チーム リーダー会 F : マネー ジャー, グループ/サブ リーダー 信頼性・拡張性WG T : インフラチーム F : 基盤グループ プロジェクト進捗会議 T : マネージャー, PMチーム F : マネージャー, グループリーダー, プロジェクト推進グループ FM/規制 チーム 進捗 T : 売買監理 チーム プロジェクト 工程会議 (毎月最終火曜日) インフラ分科会 T : インフラチーム F : 基盤グループ 開発推進チーム 端末共通分科会 T : 端末共通 F : 開発推進、クライアント開発、 アプリ基盤(端末FW) 運用 グループ 進捗会 F:運用 グループ 業務 グループ 進捗会 F: 業務 グループ 開発標準分科会 T : 開発標準 F : 開発推進 部門間定例 T : マネージャー 東証本館にて隔週開催 品質マネージメント 定例 T : 品質管理チーム F : 品質管理チーム 媒介/業務共通 分科会 T : 媒介チーム F : 媒介/業務共通チーム

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

10

-注文

約定通知

受付通知

<プロジェクト概要>

システム概要図

プライマリサイト

arrowhead

参加者

参加者

相場

東証

シス

参加者

参加者

GW

通知情

サーバ

問合せ

GW

相場情報

負荷分散

トレーディ

ングサー

バ

トレーディ

ングサー

バ

注文管理

サーバ

通知情

サーバ

トレーディング

サーバ

売買監理

サーバ

④約定通

通知情

サーバ

通知情

サーバ

取引記録

サーバ

負荷分散

取引データ

トレーディ

ングサー

バ

トレーディ

ングサー

バ

情報配信

GW

相場

セカンダリ

サイト

DB

サーバ

取引データ

トレーディ

ングサー

バ

トレーディ

ングサー

バ

外部接続

サーバ

清算情報

約定情報

負荷分散

売買情報

同期コピー

同期コピー

信頼性

拡張性

メモリDB

堅牢性

参加者毎に負荷

分散するサーバ

銘柄毎に負荷

分散するサーバ

処理量見合で負荷

分散するサーバ

凡例:

AP規模3.5Mstep

C:

2.8Mstep

Java:0.7Mstep

サーバ台数

約200台

メモリDB

メモリDB

メモリDB

メモリDB

高速性

“ミリ”秒の領域

秒レベルの領域

フロントサーバ群

バックサーバ群

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

11

-arrowhead

参加者GWサーバ

トレーディングサーバ

情報配信

GWサーバ

取引記録サーバ

取引

注文管理サーバ

データベース

サーバ

相場ユ

市場監視

サーバ

<プロジェクト概要>

処理プロセス概要図

銘柄

テーブル

注文キュー

注文キュー

注文キュー

注文キュー

注文キュー

注文キュー

注文キュー

注文キュー

注文キュー

注文キュー

データ

ベース

注文受付

(銘柄、値段等

のチェック)

受付通知送信

約定通知送信

板登録・付合せ

(マッチング)

注文キュー

(参加者単位)

付合せ情報

キュー

約定通知作成

約定履歴作成

約定通知

キュー

相場情報

キュー

取引記録

キュー(出)

情報配信

取引記録

アプリケーション

キュー *

テーブル *

板情報

赤矢印

緑矢印

:注文応答処理の流れ

(所要2ミリ秒程度)

:情報配信処理の流れ

(所要3ミリ秒程度)

注文キュー

注文キュー

注文キュー

(銘柄単位)

すべてのデータをメモ

リー上に展開、3重化 *

注文キュー

注文キュー

取引記録

キュー(受)

市場監視

フロントサーバ群

バックサーバ群

バック系サーバがダウンしても

フロント系サーバのみで売買は継続可能

サーバ間はメッセージ・キューで非同期通信

→アプリの品質やシステムの可用性を疎に分離

(3)

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

12

-0 5 10 15 20 25 30 8:008:158:308:459:009:159:309:4510:0 0 10:1 5 10:3 0 10:4 5 11:0 0 11:1 5 11:3 0 11:4 5 12:0 0 12:1 5 12:3012:4 5 13:0 0 13:1 5 13:3 0 13:4 5 14:0 0 14:1 5 14:3 0 14:4515:0 0 ミリ秒

概ねザラバ中において目標値である10ミリ秒を大幅に下回る2ミリ秒で安定。

日中を通じてほぼブレがなく、一定のレベルを保っている。

実績 2ミリ秒

実績 2ミリ秒

目標 10ミリ秒

目標 10ミリ秒

時間帯別 注文受付レスポンスの推移(2010/04/13)

注文受付

時間帯

立会時間帯

立会時間帯

<プロジェクト概要>

高速性(注文受付レスポンス)の目標と実績

0

5

10

15

20

25

30

時刻→

↑ミリ秒

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

13

-<発注者責任の明確化>

従来の開発プロセスの問題点と要因

問題点

要因

対応すべき者

発注者

受託者

① ベンダ提案の精度が低い

RFPの記述粒度が不十分

② 要件と実装の齟齬が多い

要件定義の一部に漏れや

曖昧性

③ 納品時の品質が悪い

品質管理が不十分

④ 納品遅延の予見ができない

工程管理が不十分

稼動準備状況・稼動品質の

見極めが雑駁

稼動可否チェックが不十分

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

14

-RFP

作成

①第三者(コンサル)の参画

②RFP詳細化(約1500

ページ)

詳細な要件定義書の作成

内部設計書の作成

詳細設計書の作成

東証

開発

③要件定義・外部設計の詳細化

(要件定義書+外部設計書で

4000ページ)

④第三者による品質チェック

(要件定義書の記述項目の網羅性等)

⑤内部設計と外部設計の分離

⑥外部設計の内製化

⑦注文受付から約定結果送信、相場情

報配信までの処理パターンを網羅的に

洗い出して、テストシナリオとして利用

⑧要件定義(約1万項目)が設計書に反

映されていることのトレース

提案書

評価

⑨東証とベンダーが

ひとつのプロジェクト

オフィスに集結

性能マネジメント計画書

拡張性マネジメント計画書

信頼性マネジメント計画書

⑩システム要件を確実に達

成するための手引書

要件トレース表の作成

外部設計書の作成

発注者責任の明確化

開発

ベンダー

の決定

オークションパターン

の作成

ベンダー選定プロセス

要件定義/設計プロセス

設計プロセス

<発注者責任の明確化>

開発プロセスの改善

発注者は内部的な責任をベンダ側に依存しがち。

でもトラブルが発生すれば、対外責任は全て発注者。

発注者が真に責任を負える体制が必要。

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

15

-<発注者責任の明確化>

発注者とベンダとの間のリスク共有

本プロジェクトのシステムテスト工程でのバグ密度の目標値=0.3件/kstepとし、

これを按分した0.15件/kstepを東証および開発ベンダの目標バグ密度と設定。

システムテストでのバグ密度の実績値=0.23件/kstepで、目標値をクリア。

品質の責任者

バグ混入工程

バグの原因

強化ポイント

東証

要件定義

要件の齟齬

詳細設計工程での

業務要件に関わる

レビューの強化

基本設計

業務要件の齟齬

詳細設計

業務要件の齟齬

開発ベンダ

詳細設計

実現方式の齟齬

製造工程での

単体テストの強化

製造

全般

上流工程での不具合の刈り取りを促し、下流工程への不具合のすり抜けを牽制

することを目的として、東証、開発ベンダそれぞれの責任範囲を決めて、下流のシ

ステムテストでのバグ件数の目標値を設定。

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

16

-<要件定義プロセスの高度化>

要件定義書の体系(鳥瞰図)

・全体業務フローと業務フロー図で業務の流れを俯瞰・要件の抜け漏れを確認

・それをもとに要件定義書、外部設計書を作成

要件定義書

業務フロー図

全体業務フロー

要件定義書

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

17

-<要件定義プロセスの高度化>

要件変更の分析による要件品質向上

要件定義の変更内容を1件毎にプロジェクトで審査。同時に変更内容を分析し、前工程

の悪さを引きずることのないよう品質改善策を実施。

変更管理

原因工程、発見契機、内容、傾

向を踏まえて、同様の悪さが該

当チーム、他チームに潜んでい

ないかを分析

誤字脱字も含め、要件定義に

修正を行う場合は1件毎に承認

プロセスを実施

同様の悪さが潜んでいる可能

性がある場合には、プロジェクト

横断でチェックし、アクション

分析資料

【例】

■事象

画面項目定義に「XX値段」とい

う曖昧な表現があり、そのため

に設計上で誤解が生じてい

た・・・

■アクション

プロジェクト横断でチェックし、

同様の項目や定義を行って

いるサブシステムA、サブシス

テムBについて画面項目定義、

帳票出力の項目定義を改善

■分析

同項目は他のサブシステム

でも利用しており、同様のミス

が潜んでいる可能性が高い

要件変更の内容はもとより、発生起因がベンダか東証か、発生契機が要件の検討過程、レビュー過程、方式検討

過程か等のポイントで分析。要件の不具合が摘出すべき工程で行われているかチェックし、アクションを実施

(4)

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

18

-外部設計 内部設計

<要件定義プロセスの高度化>

オークション・パターンの作成(Wモデル)

コア業務である媒介処理に係る業

務要件を中心として、旧売買シス

テムの標準テストケースをもとに

「オークションパターン」を作成。

要件定義

詳細設計

製造

ベンダテスト 受入テスト

■基本設計~内部設計

参加者-媒介処理-FM-規制-情報配信-板絵(=

端末画面)について、代表的な状態遷移・イベン

トパターンで整理し、システム全体としての要件

確認、設計の整合性の確認を行った。

どうしても方式があらあらで、かつサブシステ

ム毎に業務ロジックの設計を進めがちな中で、一

体的に設計をチェック、東証もその後のテストパ

ターンの整理が出来た。

オークションパターン

■詳細設計

媒介パターンも踏まえて作成・レ

ビューされた内部設計書をもとに詳

細設計書が作成された。

詳細設計のレビューの際にも役立

ち、設計ミスの早期発見に寄与した。

■結合テスト

結合テストのテストバリエーションの確

認において有用だった。

■受入テスト準備

上流工程で整理していたため、受入テス

トに向けて深化させ、それをベースにテ

スト準備をすることでOKになった。ま

た、テストケース作成、データ準備にも

そのまま利用することができた。

工程

実施

内容と成

各設計書へのフィードバック

PDCA

オークションパターンチェック

要件定義書

東証テストケース

オークションパターンチェック

旧システム

標準テスト

ケース

効果:

①要件の網羅性確認

②ベンダ側の具体例に基づいた要件理解

③テストケース作成へのスムーズな移行

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

19

-<要件定義プロセスの高度化>

オークション・パターン

サンプル

中項目寄前気配の場合 ID 媒-FLEX01 小項目 確認内容 現システム想定されるケース 要件定義書記載 I D 1片玉/売/指値(1~8気配)/1値段① - NO+Q1~Q8 ● 2片玉/売/指値(9気配以上含む)/1値段① - NO+Q1~Q8+QO 3片玉/売/指値(1~8気配)/1値段①+非優先注文入力 - NO+Q1~Q8 4片玉/売/指値(9気配以上含む)/1値段①+非優先注文入力 - NO+Q1~Q8+QO 22両玉/成行+指値(1~8気配)/対当価格あり - NO+Q1~Q8+QM 23両玉/成行+指値(9気配以上含む)/対当価格あり - NO+Q1~Q8+QM+QO ● 「パターンに対当値段あり」の記載について、 当パターンは、注文受付中にて対当値段がある を意味している。 よって、付合せは執行されていない。

遷移パターンを作成

各項目の詳細内容を別途作成。

オークション内部処理と外部出

力データの関係がチェックでき、

「②ベンダ側ケーススタディ的

要件理解の進展」に役立つ。

小項目ID 寄前/ザラバ :板中心値段 引累計 数量 数量 累計引 引累計 数量 数量 累計引 3030 成行 1818 3030 成行 1818 ① 12241 OVER 18 13241 OVER 18 タグ タグ 値段 時刻 数量 812 107 18 912 107 18 NO Q1 99 8:45 63 79 106 18 89 106 18 Q2 100 8:45 5 795 105 1028 895 105 1028 Q3 103 8:45 3 743 104 1038 843 104 1038 Q4 104 8:45 3 713 103 1553 813 103 1553 Q5 105 8:45 5 68 102 53 78 102 53 Q6 107 8:45 2 68 101 558 ⇒ 78 101 558 Q7 109 8:45 2 685 100 58 785 100 58 Q8 110 8:45 4 638#99#361 738 99 361 タグ 時刻 数量 時刻 数量 5510 98 364 6510#98#364 QO 8:4535 8:4338 4515 97 64 5515 97 64 30 96 569 40 96 569 30 95 574 4010 95 574 30 94 579 30 94 579 30 93 79 30 93 79 30 UNDER 48127 30 UNDER 48127 ① ② ② タグ タグ 値段 時刻 数量 30 成行 18 30 成行 18 NO Q1 98 8:47 65 35 OVER 39 OVER Q2 99 8:47 8 4 110 2 109 Q3 100 8:47 5 2 109 2 107 Q4 103 8:47 3 2 107 5 105 Q5 1 104 + 8:47 1 3 + 1 1 1 + 1 + 1 1 + 1 + 1 1 + 1 + 00000052 1 + 0 + 1 気配符号 変化フラグ 更新番号 変化フラグ 値段符号 気配フラグ 1 + △ + 変化フラグ 数量フラグ 変化フラグ 数量フラグ 1 1 + 1 + 1 1 + 1 + 1 1 + 1 + 1 1 + 1 + 1 1 + 1 + 1 1 + 1 + 1 + 1 + 1 00000051 1 + 0 + 1 値段符号 気配フラグ 気配符号 変化フラグ 連続約定気配自動執行時間60秒 更新番号 変化フラグ 特別気配表示後自動執行時間- 連続約定気配値幅 10円 23 更新値幅 5円 中項目IDFLEX01 寄前気配の場合 特別気配自動更新時間 5分 特別気配自動表示値幅 - リアル板 FLEX板 リアル板 FLEX板

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

20

-<要件トレーサビリティ>

要件トレーサビリティとは?

要件定義は完璧に作ったつもりだけど、これが、100%成果物に反映されている

ことをどう確認すればいいのか?

ひとつひとつの要件要素が設計書のどこに書かれていて、どのテスト項目で確認す

るのか、リンクがされていれば良い!

このしくみが、要件トレーサビリティ

要件定義は完璧に作ったつもりだけど、これが、100%成果物に反映されている

ことをどう確認すればいいのか?

ひとつひとつの要件要素が設計書のどこに書かれていて、どのテスト項目で確認す

るのか、リンクがされていれば良い!

このしくみが、要件トレーサビリティ

要件要素

1.1.1 xxxx

1.1.2 yyyy

1.1.3 zzzz

1.2.1 wwww

2.1.1 qqqq

基本設計

A.1.1 dddd

A.1.2 eeee

B.1.1 ffff

B.1.2 gggg

C.1.1 hhhh

詳細設計

1.1.1 xxxx

1.1.2 yyyy

1.1.3 zzzz

1.2.1 wwww

2.1.1 qqqq

2.1.2 mmmm

3.1.1 nnnn

4.1.1 vvvv

テスト項目

A.1.1 xxxx

A.1.2 yyyy

A.1.3 zzzz

B.1.1 wwww

B.1.2 qqqq

C.1.1 ssss

C.1.2 zzzz

D.1.1 rrrr

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

21

-<要件トレーサビリティ>

要件トレーサビリティ:設計フェーズ

・ 要件定義書を項目化した要件トレース表(mini要件定義書)を作成

・ どの要件項目がどの設計書に記載されているかのトレースを実施

・ 設計が変わるタイミングで部分トレースによって紐付け情報喪失を防止

ポイント

●東証⇔富士通の担当チー

ムの境界線の違い

●工程で詳細化する部分の

追加の紐付け

●バージョン管理

(要件と設計の非同期の

改訂)

次工程でさらなる活用

●テストケース作成にも利

●データベース化して自動

チェック

要件

要件トレース表(抜粋)

要件内

設計書紐付け情

EXE- 0 0 1 0 0 - 0 0 11 板とは 注文を受け付け順に「板」に登録 銘柄毎の注文を売買別、値段別に整理 同一値段の複数注文を記載するケースでは、時間的に早く 板登録した注文を中心に近く記述する 同時呼値 同時呼値とは、規則上、約定における時間優先(登録時間 順)にとらわれずに同時に受付けられたとみなされる注文 板の各値段に登録されている注文が取引参加者単位に集 計(名寄せ)され、合計注文数量の多い取引参加者から少 ない取引参加者の順に付合せ処理時の約定数量の配分を 行う。 同時呼値は、次の状況における注文 ① 始値(場単位)が決定される以前に板登録された注文 (直前の場において約定せずに引き継がれた注文含む。) ② 売買停止(市場停止を含む)から売買を再開した後の最 始値(場単位)決定時、売買停止解除後最初の約定値段 決定時、ストップ配分方式による約定値段決定時及び同一 値段に引け条件付注文が複数ある場合における立会終了 時の約定値段決定時には、その時点で有効な同時呼値を 同時呼値は、約定処理において始値等の決定後に板登録 された注文(ザラバ注文)とは区別して扱われる。同時呼値 が始値決定後に板に残っている場合、当該同時呼値と同じ 値段に登録されたザラバ注文は、当該同時呼値が全て約 引け条件付注文は、立会終了時以前の同時注文およびザ ラバ注文とは区別して扱う。 立会終了時以前の同時注文、またはザラバ注文が 立会終了時に板に残っている場合、当該注文と同じ値段に 登録された引け条件付注文は、立会終了時以前の同時注 文、およびザラバ注文が全て処理された後に約定対象とす EXE- 0 0 1 0 0 - 0 0 31

項目名

機能

関連業務

ルールID

業務

ルールID

1 2 3 4 ① 参 加 者 か ら の 新 規 / 変 更 / 取 消 注 文 入 力 ( 新 規 注 文 ) ② 参 加 者 か ら の 新 規 / 変 更 / 取 消 注 文 入 力 ( 変 更 注 文 ) ③ 参 加 者 か ら の 新 規 / 変 更 / 取 消 注 文 入 力( 取 消 注 文) ④ 取 引 所 売 買 監 理 端 末 か ら の 有 効 注 文 取 消 ⑤ 時 間 外 ま た は 場 間→ 注 文 受 付 開 始 ⑥ 注 文 受 付 中→ 立 会 開 始 ● ● ● 対応済 DA360 同時呼値の引き直し DA300 付合せ約定処理 概要、2. 同時呼値注文の配分処理 対応済 ①始値(場単位)決定時、 DA006 立会開始 1. ステータス変更処理 DA920 板寄せ方式対当値段算出時の約 定処理 ● ● ● 2.立会スケジュール 1.注文入力/変更/取消

内部設計書2

ドキュメント名

同時呼値 同時呼値とは、規則上、約定における時間優先(登録時間 順)にとらわれずに同時に受付けられたとみなされる注文 板の各値段に登録されている注文が取引参加者単位に集 計(名寄せ)され、合計注文数量の多い取引参加者から少 ない取引参加者の順に付合せ処理時の約定数量の配分を 行う。 同時呼値は、次の状況における注文 ① 始値(場単位)が決定される以前に板登録された注文 (直前の場において約定せずに引き継がれた注文含む。) ② 売買停止(市場停止を含む)から売買を再開した後の最 対応済 DA360 同時呼値の引き直し DA300 付合せ約定処理 概要、2. 同時呼値注文の配分処理 EXE- 0 0 1 0 0 - 0 0 11 板とは 注文を受け付け順に「板」に登録 銘柄毎の注文を売買別、値段別に整理 同一値段の複数注文を記載するケースでは、時間的に早く 板登録した注文を中心に近く記述する 同時呼値 同時呼値とは、規則上、約定における時間優先(登録時間 順)にとらわれずに同時に受付けられたとみなされる注文 板の各値段に登録されている注文が取引参加者単位に集 計(名寄せ)され、合計注文数量の多い取引参加者から少 ない取引参加者の順に付合せ処理時の約定数量の配分を 行う。 同時呼値は、次の状況における注文 ① 始値(場単位)が決定される以前に板登録された注文 (直前の場において約定せずに引き継がれた注文含む。) ② 売買停止(市場停止を含む)から売買を再開した後の最 始値(場単位)決定時、売買停止解除後最初の約定値段 決定時、ストップ配分方式による約定値段決定時及び同一 値段に引け条件付注文が複数ある場合における立会終了 時の約定値段決定時には、その時点で有効な同時呼値を 同時呼値は、約定処理において始値等の決定後に板登録 された注文(ザラバ注文)とは区別して扱われる。同時呼値 が始値決定後に板に残っている場合、当該同時呼値と同じ 値段に登録されたザラバ注文は、当該同時呼値が全て約 引け条件付注文は、立会終了時以前の同時注文およびザ ラバ注文とは区別して扱う。 立会終了時以前の同時注文、またはザラバ注文が 立会終了時に板に残っている場合、当該注文と同じ値段に 登録された引け条件付注文は、立会終了時以前の同時注 文、およびザラバ注文が全て処理された後に約定対象とす EXE- 0 0 1 0 0 - 0 0 31

項目名

機能

関連業務

ルールID

業務

ルールID

1 2 3 4 ① 参 加 者 か ら の 新 規 / 変 更 / 取 消 注 文 入 力 ( 新 規 注 文 ) ② 参 加 者 か ら の 新 規 / 変 更 / 取 消 注 文 入 力 ( 変 更 注 文 ) ③ 参 加 者 か ら の 新 規 / 変 更 / 取 消 注 文 入 力( 取 消 注 文) ④ 取 引 所 売 買 監 理 端 末 か ら の 有 効 注 文 取 消 ⑤ 時 間 外 ま た は 場 間→ 注 文 受 付 開 始 ⑥ 注 文 受 付 中→ 立 会 開 始 ● ● ● 対応済 DA360 同時呼値の引き直し DA300 付合せ約定処理 概要、2. 同時呼値注文の配分処理 対応済 ①始値(場単位)決定時、 DA006 立会開始 1. ステータス変更処理 DA920 板寄せ方式対当値段算出時の約 定処理 ● ● ● 2.立会スケジュール 1.注文入力/変更/取消

内部設計書2

ドキュメント名

同時呼値 同時呼値とは、規則上、約定における時間優先(登録時間 順)にとらわれずに同時に受付けられたとみなされる注文 板の各値段に登録されている注文が取引参加者単位に集 計(名寄せ)され、合計注文数量の多い取引参加者から少 ない取引参加者の順に付合せ処理時の約定数量の配分を 行う。 同時呼値は、次の状況における注文 ① 始値(場単位)が決定される以前に板登録された注文 (直前の場において約定せずに引き継がれた注文含む。) ② 売買停止(市場停止を含む)から売買を再開した後の最 対応済 DA360 同時呼値の引き直し DA300 付合せ約定処理 概要、2. 同時呼値注文の配分処理

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

22

-<要件トレーサビリティ>

要件トレーサビリティ:結合テスト・システムテスト

・ 要件と結合テスト・システムテストのテストケースの紐付けにより要件網羅性の確認

ポイント

●要件一覧の常時最新化

●評価タイミングの妥当性

●障害発生時に未充足状態へ戻り

次工程でさらなる活用

●東証内確認でのクロスチェック

●データベース化して集計簡略化

<結合テスト・システムテストフェーズでの要件トレーサビリティ確保プロセス>

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

23

-<要件トレーサビリティ>

要件トレーサビリティ:受入テストフェーズ

・要件要素ID、設計書ID、受入テストIDを紐付けて一元管理

・充足状況をリアルタイムで可視化

ポイント

●要件要素、テストケースの

粒度設定

●システム全体での一律管理

●要件充足進捗の妥当性評価

●要件定義書の世代管理によ

り、追加や変更の要件充足

確認漏れの防止

(要件定義完了時:11,000件

⇒ 稼働時:12,000件)

稼働後でさらなる活用

●要件変更に対応

●ノウハウの他プロジェクト

への展開

集計・分析

<要件トレーサビリティの管理イメージ>

テストケースID テストケース名世 代チーム大分類 中分類 小分類 想定結果 ケース 内 件数 要件要素ID 設計書ID HBV50-0020001初期画面表示時の検索 条件 1HBV50:発注状況002:画面レイ ア ウト 0001:メニュー画面から 遷移した場合の検索条 検索条件には、以下の値が表示されている こと ※ここに記載が無い項目は「空白」となる 1 MON-00200-006_10.2.1.0 HBv0050 HBV50-0020002成行を 含むチェ ックボッ クス 1HBV50:発注状況002:画面レイ ア ウト 0002:成行を 含むチェ ッ クボックス=ON 範囲指定した注文値段と一緒に、成行注文も表示される こと ※検索条件の 1 MON-00200-006_40.26.0.0 HBv0050 HBV50-0020003取引所ごとに異なる 市 場区分の表示確認 1HBV50:発注状況002:画面レイ ア ウト 0003:プ ルダウン リスト: 市場区分 取引所区分に応じた市場区分が選択できる こと ※ただし、00:全市場は選択不可 1 MON-00200-006_40.3.0.0;MON-HBv0050 HBV50-0020004同一注文の不変項目非 表示 1HBV50:発注状況002:画面レイ ア ウト 0004:同一注文情報の非 表示対象項目 同一注文の2行目以降は、以下の項目値が表示されないこと(空白とな る ) 1 MON-00200-006_40.12.0.0 HBv0050 HBV50-0020005成行注文の値段欄表示 1HBV50:発注状況002:画面レイ ア ウト 0005:成行注文の値段表 示 注文値段が成行の場合は、”成行”と表示する こと 1 MON-00200-006_40.14.0.0 HBv0050 HBV50-0030001参加者検索のショ ート カ ットキー D1HBV50:発注状況003:画面イ ベン ト 0001:参加者検索の ショ ートカ ットキーが有 ショ ートカ ットキー(F4)押下によ る 参加者検索機能が有効となる のは、 検索条件の参加者コード1(最上段)のみである こと 1 UIF-00100-001_30.9.1.0 HBv0050 HBV50-0030002並び順を 指定した検索 結果表示(受付時刻順)1HBV50:発注状況003:画面イ ベン ト 0002:表示順=<1:受付 時刻順>で照会 照会結果の並び順が、注文受付番号ごとに、新規注文の注文時刻の昇 順に表示され、その各注文受付番号内の取引は、板更新回数の昇順に1 MON-00200-006_40.28.0.0;MONHBv0050 HBV50-0030003並び順を 指定した検索 結果表示(値段順) 1HBV50:発注状況003:画面イ ベン ト 0003:表示順=<2:値段 順>で照会 照会結果の並び順が、注文受付番号ごとに、新規注文の値段の降順に 表示され、その各注文受付番号内の取引は、板更新回数の昇順に表示1 MON-00200-006_40.28.0.0 HBv0050 HBV50-0030004銘柄コードを 指定しない (未入力)状態で、共通D1HBV50:発注状況003:画面イ ベン ト 0004:銘柄コードが未入 力 プ ルダウン の共通ヘッダ表示が、”無し”となり、編集不可能となる こと 1 MON-00200-006_30.1.0.0 HBv0050 HBV50-0030005共通ヘッダ画面が開設 していない状態で、共通1HBV50:発注状況003:画面イ ベン ト 0005:共通ヘッダ表示= <1:有>、かつ共通ヘッ 発注状況の照会結果が表示される のと同時に、共通ヘッダ画面が自動 で表示、照会が行われる こと 1 MON-00200-006_40.1.0.0;MON-HBv0050 HBV50-0030006共通ヘッダ画面が既に 開設している 状態で、共D1HBV50:発注状況003:画面イ ベン ト 0006:共通ヘッダ表示= <1:有>、かつ共通ヘッ 発注状況の照会結果が表示される のと同時に、共通ヘッダ画面の内容 が更新される こと 1 MON-00200-006_40.1.0.0;MON-HBv0050 HBV50-0030007共通ヘッダ画面が開設 していない状態で、共通D1HBV50:発注状況003:画面イ ベン ト 0007:共通ヘッダ表示= <0:無>、かつ共通ヘッ 共通ヘッダ画面は表示されないこと 1 MON-00200-006_40.1.0.0;MON-HBv0050 HBV50-0030008共通ヘッダ画面が既に 開設している 状態で、共D1HBV50:発注状況003:画面イ ベン ト 0008:共通ヘッダ表示= <0:無>、かつ共通ヘッ 共通ヘッダ画面の表示内容は、更新されないこと 1 MON-00200-006_40.1.0.0;MON-HBv0050 HBV50-0030009符号・通知番号表示設 定の確認 1HBV50:発注状況003:画面イ ベン ト 0009:「符号通知番号表 示」を <0:無>とした場 照会した結果について、「銘柄コード」「上場区分」「整理監理区分」「信用 貸借区分」「権利落ち 符号」「参加者コード」「社内処理用項目」「板更新 1 MON-00200-006_30.2.0.0 HBv0050

テストケースと要件をIDで紐付けて管理

テストケースID

テストケース名

HBV50-0020001初期画面表示時の検索 条件 1 HBV50-0020002成行を 含むチェ ックボックス 1 HBV50-0020003取引所ごとに異なる 市 場区分の表示確認 1 HBV50-0020004同一注文の不変項目非 表示 1 HBV50-0020005成行注文の値段欄表示1

要件要素ID

MON-00200-006_10.2.1.0 MON-00200-006_40.26.0.0 MON-00200- 006_40.3.0.0;MON- MON-00200-006_40.12.0.0 MON-00200-006_40.14.0.0

受入テストにおける要件充足状況

(5)

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

24

-結合テスト

システムテスト

受入テスト

<要件トレーサビリティ>

要件トレース実施による効果

・各工程での成果物に対して、要件充足(総数:11,000件、機能要件:10,500件、非機能要件:500件)を

トレースして、開発システムの要件実装性を高める。

内部設計

詳細設計

製造

受入テストでの要件定義起因と外部設計起因のバク

を削減できた。(当該バグの内、約86%を設計工程

で摘出。)

設計進度に合わせて、要件充足を確認できた。

要件定義の不備を適時修正し、設計書へ反映するこ

とができた。

手戻り工数を減らすことができた。

ベンダと東証側の連携ができた。

要件未達部分に対し、適時対策を実施するこ

とができた。

要件充足の完了を確認できた。

工程

効果

充足率:

67.4%

充足率:

86.5%

充足率:

98.0%

充足率:

100%

設計書レビュ結果による要件充足を

トレース

テスト項目および結果の要件充足を

トレース

(残分→詳細設計

で確認)

(残分→課題管理で対応)

(残分→稼動判定

までに対応)

機能設計

処理設計

充足率:

94.4%

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

25

-<フィードバック型V字モデル>

フィードバック型V字モデルとは?

プログラミングをする際、設計書上の不整合や情報の不足、曖昧さ等を発見することがよ

くありませんか?

プログラムを作るだけを目的とせず、設計書の品質向上も目的としてプログラミング工程

をすすめれば、設計書の不具合状況を管理し評価することで、設計書の品質向上を図るこ

とができる!

これをすべての工程で行うのが、フィードバック型V字モデル

プログラミングをする際、設計書上の不整合や情報の不足、曖昧さ等を発見することがよ

くありませんか?

プログラムを作るだけを目的とせず、設計書の品質向上も目的としてプログラミング工程

をすすめれば、設計書の不具合状況を管理し評価することで、設計書の品質向上を図るこ

とができる!

これをすべての工程で行うのが、フィードバック型V字モデル

前工程の

成果物

現工程の

成果物

成果物作成

(コーディング等)

成果物

レビュー

現工程

前工程

更なる品質向上

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

26

-<フィードバック型V字モデル>

従来のV字モデル

コーディング

要件定義

要件定義書

レビュー

基本設計

基本設計書

レビュー

詳細設計

詳細設計書

レビュー

プログラム設計

プログラム設計書

レビュー

単体テスト

テスト項目

テスト実施

結合テスト

テスト項目

テスト実施

システムテスト

テスト項目

テスト実施

運用テスト

テスト項目

テスト実施

要件エラー発見

基本設計エラー発見

詳細設計エラー発見

修正-手戻

修正-手戻

修正-手戻

PG設計エラー・

コーディングバグ発見

修正-手戻

・設計段階では、各設計書レビューが完了したら工程終了。

・次工程は、前工程の設計書を正として、詳細化を実施。

・テスト項目は各テスト実施時期の直前(或いは並行して)作成されがち。

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

27

-<フィードバック型V字モデル>

フィードバック型V字モデル

コーディング

要件定義

要件定義書

レビュー

基本設計

基本設計書

レビュー

詳細設計

詳細設計書

レビュー

プログラム設計

プログラム設計書

レビュー

単体テスト

テスト項目

テスト実施

結合テスト

テスト項目

テスト実施

システム確認

テスト項目

テスト実施

運用確認

テスト項目

テスト実施

要件定義書品質向上

基本設計書品質向上

詳細設計書品質向上

PG書品質向上

テスト項目抽出による品質向上(Wモデル)に加えて、前工程の不具合を傾向分析し、品質状況を評価する。

前工程の成果物の弱点が見つかったら、前工程に立ち戻って品質強化を行い、手戻りを未然に防止する。

要件定義書品質強化

基本設計書品質強化

詳細設計書品質強化

PG書品質強化

Wモデル

Wモデル

フィードバック

モデル

フィードバック

型V字モデル

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

28

-<フィードバック型V字モデル>

フィードバック型V字モデルで想定される効果

V字モデルの場合(

赤曲線)

・コーディングは設計書を正として行い、単体テストは

ホワイトボックス主体で行うため、設計書に内在す

るエラーを摘出しずらい。

・設計書の内在エラーは結合テストで検出するというV

字モデルの考え方のため、結合テストでの設計書内

在エラー摘出を当然と考えがちである。

⇒従って結合テスト工程まで設計の内在エラーが残るた

め、その分の手戻り工数が増加し、結果的に結合テ

スト工程遅延要因となる。

コーディング

単体テスト

結合テスト

設計レビュー

完了時の

設計エラー

残存件数

結合テストまですり抜けた

設計エラー数

V字モデル

FVモデル

フィードバック型V字モデルの場合(青曲線)

コーディング時に設計書内容を厳密に確

認し設計バグ摘出を意識するため、内在

エラーもその殆どをここで摘出すること

ができる。

⇒従って設計修正及び設計品質確認をコーディン

グ期間中にほぼ完了させることができる。

⇒結合テストまで設計エラーを残さないためトー

タルの手戻り工数は非常に少なく抑えることが

できる。

設計レビュー完了以降の設計エラー残存件数の推移

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

29

-<タスクの優先度付け>

重み付けプロジェクトマネジメント

サブシステム

利用者

要求レベル

プログラム

規模

品質

性能

納期

共通

証券会社、相場情報ベンダー

900kstep

参加者接続

証券会社(+投資家)

注文付合せ

証券会社(+投資家)

相場情報配信

相場情報ベンダー

売買監理

社内売買監理部門

2,600kstep

清算データ連携

社内清算システム

運用支援

社内運用部門

市場統計情報

社内売買審査部門

テスト支援

社内開発部門

サブシステム毎に品質、性能、納期などの要求レベルを評価

開発リソースとマネジメントリソースの配置を重み付け

(6)

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

30

-<タスクの優先度付け>

本番稼働間際における障害仕分け

・本番稼働前2ヶ月間に発生した障害は、業務影響度と修正リスクとを勘案して、

稼働前に改修するか、当面は運用対処として稼動後の改修とするかを判断。

ランク

定義

発生件数

A

業務影響があり、稼動までに対処が必要

91

B

運用回避が可能だが、修正が軽微

16

C

運用回避が可能で、業務影響が軽微

64

D

ドキュメントのみの修正

25

バグ修正を稼働後に延期する

ことで、システム変更に伴う

リスクを回避。

システムの中核となる媒介は0件。

参加者接続、情報配信は1件ずつ

のみ。(計2件)

残り89件は、周辺業務でのバグ。

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

31

-<リスク管理>

arrowheadにおけるリスク管理の特徴

1.リスクの“発生確率レベル”と発生時の“影響度”でスコア付け

2.リスク“発生確率レベル”の低減計画を策定し、予実管理を実施

3.リスクが顕在化したら、影響度を1.5倍に拡大し、重点的に管理

4.全リスクの予定スコア合計と実績スコア合計を比較⇒プロジェクト全体のリスク低減状況をチェック

1.リスクスコアの算出方法

発生確率レベル

×

影響度

リスクスコア

・リスクスコアが「3」以上のリスクをプロジェクトでの

管理対象とした。

・リスクスコアが「6」以上のリスクを工程会議において

モニタリングすることとした。

7段階に分類し、管理

⇒ 次ページの具体例参照

リスクが顕在化した場合の

影響度を3段階で評価

影響度

評価内容

3

プロジェクトのベースラインに

影響を与える場合

2

プロジェクトで吸収可能な中程度

の影響を与える場合

1

影響が軽微な場合

リスクと課題の一元管理

①リスクが課題化したら

⇒影響度を1.5倍に拡大

②課題が解決したら

⇒影響度を元の値に戻す

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

32

-<リスク管理>

リスクの低減計画と予定/実績管理

「プロジェクトにおいて計画されている作業やイベントの実行」と「リスク発生確率レベルの低減」との関連性を、

あらかじめ定義し、計画どおりに作業等が実行されたことによりリスクスコアが低減していたことを確認する。

発生確率

レベル

リスクに関する状況

モニタリング

実現時期

監視内容

3

プロトコルを一新することについて、参加者の理解を

得られていない

2.5

新プロトコルにおける主要な変更点について参加者の

理解が得られている

2006年9月

CIO-M、実務者-Mで新プロトコルの

方針について合意することを確認

2

大手、外資等の代表的な参加者に新プロトコル案を提

示し、合意が得られている

2007年3月

実務者-Mで新プロトコルdraft(第0版)

を提示し、合意、することを確認

1.5

全参加者に新プロトコル案を提示し、合意が得られて

いる

2007年5月

参加者説明会で新プロトコルdraft(第0

版)を提示し、合意することを確認

1

全参加者に新プロトコルを確定仕様として提示してい

2007年7月

第2回参加者説明会で新プロトコル(第1

版)を提示し、合意することを確認

0.5

パイロットユーザテストで新プロトコルに関連する問

題が生じない、または生じた問題への対応が完了する

2009年2月

パイロット参加者による実機テストで問題

なく接続可能であることを確認

0

参加者接続テストで新プロトコルに関連する問題が生

じない、または生じた問題への対応が完了する

2009年10月

参加者接続テストを問題なく実施できるこ

とを確認

<リスク低減計画例:取引参加者が新プロトコルに対応できないリスク>

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

33

-<リスク管理>

プロジェクト全体のリスク状況把握

個別のリスクについての予定/実績管理を行うとともに、全リスクの予定リスクスコアの合計値と

実績リスクスコアの合計値を比較管理することにより、プロジェクト全体のリスク状況の把握を行っ

た。

0 50 100 150 200 250 300 350 400 450 2006年7月 2006年11月 2007年3月 2007年7月 2007年11月 2008年3月 2008年7月 2008年11月 2009年3月 2009年7月 2009年11月

実績スコア

予定スコア

ポイント

図:全体リスクスコアの推移グラフ

予実のギャップ

を継続管理

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.

-

34

-ご清聴ありがとうございました

株式会社東京証券取引所グループは、東日本大震災の

被害に対して、投資家をはじめとした幅広い市場利用

者の皆様と共にできる復興支援策として、本年4月~9

月までのETF(上場投資信託)の売買手数料に相当

する金額を東日本大震災への義援金として寄付するこ

とといたしました。なお、今後新たに上場する枠組み

ができているETN(指数連動証券)についても、義援

金の対象といたします。

http://www.tse.or.jp

HOME>上場商品>ETF>ETFスクエア

東京証券取引所は、ETFの売買手数料を

東日本大震災に対する義援金として拠出します

~ETFの売買が復興支援につながります~

FUJITSU CONFIDENTIAL

Copyright 2010 FUJITSU LIMITED

東証株式売買システムarrowhead開発の振返り

<コアファクターの実現に向けて>

東証株式売買システムarrowhead開発の振返り

<コアファクターの実現に向けて>

2011年9月9日

富士通株式会社

保険証券ソリューション事業本部)東証事業部

三澤

SQiP2011

Updating...

参照

Updating...

関連した話題 :