• ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
  • 日経BP
  • PR

  • PR

  • PR

  • PR

  • PR

東証、世界に挑む300億円プロジェクト

機能要件は3階層で整理

2009/01/14 日経コンピュータ
出典:日経コンピュータ 2008年11月1日号pp.104-108
(記事は執筆時の情報に基づいており、現在では異なる場合があります)
目次一覧

東京証券取引所 IT開発部arrowheadシステム部長 宇治 浩明
arrowhead担当マネージャー 川井 洋毅

 三つの取り組みを詳しく説明しよう。まず一つめの3階層に整理した機能要件の定義資料が図3だ。

図3●要件定義・外部設計の成果物の例
上はarrowheadの全体機能と利用者や接続システムを示す「全体業務フロー図」。中は業務単位で機能間の連携をまとめた図。下は機能をさらに細分化して要件を記述したもの
[画像のクリックで拡大表示]

 最上位層に当たるのが左上の「全体業務フロー図」。arrowheadを中心に配置し、接続先システムやシステムの利用者を周辺に並べて、それらの関係性を図式化した。

 全体業務フロー図の狙いは、1枚の資料でシステム全体を俯瞰できるようにすることだ。「注文処理」や「情報配信」「取引規制」などの機能群を、どの粒度でどのように分類するのが最善かを検討しやすくなると期待した。

 記述が細かすぎると全体を直感的に把握できない。かといって大ざっぱすぎても意味がないので、粒度には気を配った。今回は外部に位置する接続先システムや利用者などの「アクター」と呼ぶ存在に着目して機能群を分けた。arrowheadが処理するデータはアクターから入ってくる。出力先もアクターだ。アクターの種類に応じて機能群を分類すれば、機能群のつながりが疎結合となり、プログラム構成を最もシンプルかつ正規化した形にできると考えた。

 全体業務フロー図は、UML(統一モデリング言語)のユースケース図に似ている。ただし完全に準拠してはいない。UMLを熟知したメンバーばかりではないので、完全準拠にはこだわらず使いやすい形にカスタマイズした。

 2階層目の「業務フロー図」には、「注文処理」「情報配信」などの具体的な業務処理を進めるとき、機能群がどのようにメッセージをやり取りするかを記述した。さらに「注文処理」といった機能群を細分化した業務要件を3階層目の「要件定義書」に記載した。

「Wモデル」で上流から検収準備

 二つめの挑戦的な取り組みは、「検収テスト」フェーズで使うチェックリストの作成開始を大幅に早めたこと。検収テストの直前に作るのではなく、要件定義フェーズから着手し、手戻りの削減を狙った。

 要件定義書の内容は検収テストで、外部設計書は総合テストで、プログラムは単体テストで、それぞれ誤りがないか確認するのが一般的だ。「V字モデル」と呼ぶテスト方法である。

 この方法だと検収テストで不具合が見つかったときの手戻りが膨らむ。要件定義書を直してそこから関連する設計書を直し、プログラムを直して単体、結合、総合、検収の各テストをやり直さなければならない。

 そこで今回のプロジェクトでは、V字モデルの欠点を補う「Wモデル」という考え方を取り入れた。テストの実施を待たずに、テスト計画書やチェックリストの作成に上流工程から取り掛かる手法だ。例えば要件定義と同時に検収テストを、外部設計と同時に総合テストを始める。

ここから先はITpro会員(無料)の登録が必要です。

次ページ Wモデルを採用すると検収テストでの手戻りが減る
  • 1
  • 2
  • 3

あなたにお薦め

連載新着

連載目次を見る

今のおすすめ記事

ITpro SPECIALPR

What’s New!

経営

アプリケーション/DB/ミドルウエア

クラウド

運用管理

設計/開発

クライアント/OA機器

ネットワーク/通信サービス

セキュリティ

もっと見る