「システム開発地図」の使い方と作り方 第3回:もう迷わないシステム開発(4/4 ページ)
システム開発を進める上で強力なトレーサビリティーツールとなる「システム開発地図(System Development Map)」について解説。第3回は、地図の見方と、業務フローを記述する具体的な手順を解説します。
ユースケースモデルをブラッシュアップする
後続の「ユースケースモデルをブラッシュアップする」に関しても簡単に説明しましょう。おおよそ以下のような作業をしながら、ユースケースモデルを洗練化させていきます。
- システムを利用することを意識して、共通化できそうなユースケースに分解する
- システムアクターを抽出する
- 概念的に類似したユースケースや、あるユースケースの一部となるユースケースを識別・分類する
- 類似点の目安として、システムの振る舞いや、扱う概念クラスに着目します
- ユースケース間に汎化、包含(include)、拡張(extend)の関係を付ける
- ユースケース記述(詳細、ドラフト)を書く
- アクティビティー-ユースケース対応表を更新する。
- 事前条件、事後条件、基本系列、代替系列、例外系列を記述する
- ビジネスルールとの関係を記述する
まとめ
システム開発地図から、「業務フローを記述する」〜「ラフなユースケースモデルを作成する」〜「ユースケースモデルをブラッシュアップする」の部分を取り上げ、作業と成果物のつながりを追ってみました。UMLでモデリングするだけでなく、作業間の整合性を取るため対応表などを同時に管理することで、トレーサビリティーを確保している様子がお分かりいただけたかと思います。
業務フローなどは指針なく描き始めると際限なく時間を浪費してしまいがちです。課題となっている業務や、システム化されている(システム化したい)業務などに絞って作業をし、分かりきっている部分は描かない、重要でない部分は大ざっぱにするなど、目的を考慮して省力化することも大切です。
著者プロフィル:今田忠博
SIの現場でSE、PMなどを経験。SI現場で悲惨な体験をし、開発現場を効率的にしたいと2004年に豆蔵に移籍。アーキテクトやフレームワークの設計・実装、PM支援、要件定義コンサルタントなどの業務を経験。そもそも要求が間違っていると、そのあといくらがんばっても幸せになれないと理解する。現在は保守の効率化のため、自動打鍵テストの省力化に取組中。
著者プロフィル:近藤正裕
豆蔵 技術コンサルティング事業部に所属するITアーキテクト。ユーザー系企業でシステム開発、研究開発を担当し、2003年から現職。Java/.NET によるエンタープライズシステム開発を多数手掛ける。アーキテクチャ構築、フレームワーク開発、開発者向けガイド作成、各種自動化を実施してプロジェクトを推進するとともに、アプリケーション品質・開発効率の向上を目指す。
関連記事
- 「システム開発地図」でトレーサビリティーを導入しよう! 第1回
システム開発を進める上で強力なトレーサビリティーツールとなる「システム開発地図(System Development Map)」について解説します。第1回目は、システム開発にトレーサビリティーの導入が必要な背景やメリットを考察します。 - 第4回 フロー図で理解するセキュリティインシデントの対応
情報セキュリティにかかわるインシデントが起きれば、どうすればいいのだろうか。担当者や対応方法は決まっているだろうか? 今回はこの「インシデント対応」について考えてみたい。 - Microsoft、企業向けIFTTT的サービス「Microsoft Flow」を正式公開
Microsoftが4月にプレビュー公開した企業向けワークフロー自動化ツール「Microsoft Flow」を公式版として公開した。有料プランは1人当たり月額5ドルと15ドルの2種類あり、Salesforceとの連係は有料プランでのみ可能になる。 - 仮想環境における「うるさい隣人」問題
サーバの仮想化環境の普及とともに、ストレージへの負荷が課題となるケースも増えている。ストレージの“うるさい隣人(ノイジーネイバー)”問題を解決するため、チェックすべき5つのポイントを解説する。
関連リンク
Copyright © ITmedia, Inc. All Rights Reserved.