Open Knowledge System(9)

　今回は、knowledgeをCRUDするユースケースシナリオをロバストネス分析します。

　Rは前回分析済みですので、残りのCUDに該当するユースケースとユースケースシナリオを下図のように配置しました。これは今回の作業をしやすいようにした状態ですので、ロバストネス分析が終わればロバストネスモデル以外は破棄します。なお、私は全体の関係を一望にしたいので、下図のようにひとつのモデルとして描いていきます。モデルを分割するかどうかはお好みでよいのでしょうが、要素の関係をトレースできることが失われないように注意が必要だと思います。
　＊言い方を変えると、私は「うっかり」が多いので、それを予防するためにも全体を見ながら作業します。今回の作業用モデルも、その一環です。
　
　下図中、灰色のダイアグラムは前回分析が終了したもの、薄いピンクが今回抽出したもの、赤字で示した「ユーザーを認証する」コントロールは、前回までは「トップページを表示する」コントロールでしたが、今回の分析により、管理者だけがknowledgeを削除できるという要件を再認識したので、修正しました。

　knowledgeを更新・削除するユースケースシナリオには、knowledgeを世代管理するための記述があります。このことは、世代管理のためのコントロールの出現を予感させますが、今回は「knowledgeを更新する」と「knowledgeを削除する」のふたつのコントロールに内包されているという解釈のもと、別のコントロールに分けることはしませんでした。knowledgeの世代管理に関するユースケースシナリオは他にもありますので、その分析時に世代管理の的確なモデル化ができると予想しています。

追記

　ひとつコントロールを見落としていたので追加しました。

　knowledge追加画面には、更新者などをデフォルト値としてセットしておいた方が良さそうです。そこで、「knowledge追加画面を表示する」コントロールを追加しました。

続く…

Open Knowledge System(8)

　今回は、「新着のknowledgeを新着リストに表示する」ユースケースとprecedesの関係にある「knowledgeを参照できる」ユースケースをロバストネス分析します。
　まず、「新着のknowledgeを新着リストに表示する」ユースケースのユースケースシナリオは、修正前は不要ですのでモデルから削除します。次に、「knowledgeを参照できる」ユースケースのユースケースシナリオをノートに表示させます。この辺の作業は、Enterprise Architectを使うととても効率的に行えます。

　これで準備完了です。

　ユースケースシナリオを読みながら、「knowledge参照画面」バウンダリ、「knowledgeを表示する」コントロールを抽出し、「knowledge」エンティティは前回抽出したものに関係線をつなぎます。

　＊灰色のクラスは前回抽出したもの。薄いピンクは今回抽出したもの。

　さて、問題はprecedesと表現した関係をどう分析するかです。まずは、青色で表示しているユースケースシナリオから「新着リストで選択されたknowledgeの識別子を渡す」コントロールを抽出し、上記図のように分析しました。んんぅ？　何かしっくりきませんね…

　ふたつのユースケースは本当にprecedesの関係なのでしょうか？

　precedesとinvokesの意味を今一度確認すると、ユースケースモデルにそもそもの間違いがあることに気づきました。そこで、下図のように修正しました。

　ユースケースがひとつ足りなかったのです。これにより、

1. 
   
    「新着のknowledgeを新着リストに表示する」ユースケースの後に、「新着リストのknowledgeを参照する」ユースケースがあり、
2. 
   
   「新着リストのknowledgeを参照する」ユースケースは、「knowledgeを参照できる」ユースケースを呼び出す。

　というすっきりとした関係になります。

　Open Knowledge Systemシリーズは入門講座ではありません。ですから今回の間違いは、実際に私が犯した間違いです。しかし、このように正しい手順でプロセスを重ねていけば、間違いを発見し修正できるのです。

　先人たちの知恵、素晴らしいですね。

続く…

　

Open Knowledge System(7)

　ユースケースシナリオを書き終えたところで、ユースケースシナリオのレビューと予備設計を同時に行えるロバストネス分析に入りたいと思います。
　今の考えとしては、ロバストネス分析によってシステム全体の関連性を確認してから、RDRAの画面帳票モデル、機能モデル、データモデルにバウンダリ、コントロール、エンティティを落とし込んではどうか？　と思っています。かなり冗長なイメージですが、実験プロジェクトですので、トライしてみます。また、RDRAの機能モデルとICONIXのコントロール、この違いも（教科書を読んだだけではなく）体験として捉えることができるかもしれません。ということで、作業に入りましょう。

　最初に選んだユースケースは、

　新着のknowledgeを新着リストに表示する

　そしてユースケースシナリオは、

1. システムは、トップページを表示する時に、現在の日付から7日前までに作成（更新）されたknowledgeを、作成（更新）された順番の新しいものから順番に表示する。
2. ユーザーは、トップページにアクセスした時に、新着リストを参照する。
3. ユーザーは、新着リストの項目を選び、該当するknowledgeを参照する。

　ICONIXプロセスの教えによれば、ユースケースシナリオがしっかりしていれば、バウンダリ、コントロール、エンティティの抽出は簡単に行えるはずです。試してみましょう。

　ユースケースシナリオを読みながら、順番にクラスを抽出していきます。

1. トップページ（バウンダリ）
2. トップページを表示する（コントロール）
3. おっと、ここでユースケースシナリオの不備が見つかりました。新しいものから順番に表示するものは何？　それは新着リストであることが読み取れません。ですから、 新しいものから順番に新着リストに表示する、とユースケースシナリオを修正します。これで新着リストを表示する（コントロール）を見つけることができました。
4. トップページを表示する（コントロール）は、具体的に何をするのかよく分かりませんが、新着リストを表示する（コントロール）は、ユースケースシナリオによって明らかになっています。これにより、knowledge（エンティティ）が発見され、新着リストを表示する（コントロール）と結びつきます。

　素晴らしですね。実にシステマティックです。

　ユースケースシナリオの最後に「…該当するknowledgeを参照する」が残っていますが、このシナリオには独立した「knowledgeを参照する」ユースケースが用意されていて、これとprecedesの関係であることがユースケースモデルによって明らかにされています。ですから、最後の参照部分はここでは扱いません。

　下の図は、この作業の一場面をキャプチャーしたものです。

　ご覧のように、ユースケースシナリオとそのオーナーであるユースケース、関係するユースケースを眺めながら、先のようにシナリオを読み進めれば、簡単にロバストネス分析は終了します。また、この作業を通じてユースケースシナリオのレビューを行うことができます。

　また必要により、図のように新旧のユースケースシナリオを並べておくと、ユーザー（要求者）とのコミュニケーションなどに役立つかもしれません。

続く…

Open Knowledge System(6)

　ユースケースシナリオができたので、ここでOpen Knowledge Systemの「規模」を見積もってみたいと思います。手法には、「アジャイルな見積りと計画づくり」に紹介されているストーリーポイントを使ってみます。

　私のやり方は、Enterprise Architectからユースケース名とユースケースシナリオを出力し、一つひとつのユースケースを下写真のようにカード化し、全体を眺めながらストーリーポイントを与えていきます。ストーリーポイントは相対評価ですので、これとこれはどっちが大きい？　というような比較の時、物理的なカードは非常に処理しやすいインターフェースです。個人的にも、このようなアナログ作業は好みです。

　19あるユースケースカードを、下写真のように1、2、3、5、8、10の各ポイントに割り振っていきます。

　この作業の結果は以下のとおりです。

　ユースケース（ストーリーポイント）

1. knowledgeが更新された時、更新前のknowledgeを世代管理する (5)
2. knowledgeを全文検索できる (3)
3. knowledgeを削除できる (2)
4. knowledgeを参照できる (2)
5. knowledgeを更新できる (3)
6. knowledgeを追加できる (3)
7. ブックマークを削除する (2)
8. ブックマークを追加する (3)
9. ブックマークリストを表示する (8)
10. ラベルでknowledgeを絞り込める (2)
11. ラベルを削除できる (2)
12. ラベルリストから複数のラベルを選択し、knowledgeに付けることができる (3)
13. ラベルリストを表示する (1)
14. 世代管理されたknowledgeを公開中のknowledgeと交換できる (10)
15. 人気のknowledgeを人気リストに表示する (5)
16. 任意のラベルをラベルリストに追加できる (2)
17. 新着のknowledgeを新着リストに表示する (2)
18. 誤って更新されたknowledgeを知ることができる (1)
19. 誤って更新してしまったknowledgeには誤修正フラグを付けられる (3)

　 ストーリーポイント合計：62

　現時点で、Open Knowledge Systemの規模は、62ストーリーポイントであることが分かりました。次は、規模から期間を導出することになりますが、それはまたの機会に行うことにします。

続く…

Open Knowledge System(5)

　今回は、ユースケースにユースケースシナリオを記述します。

　私は、できるだけ全体の構造（関係）を見ながらモデリングを行いたいので、ユースケースシナリオを含めたユースケース図は、ご覧のような大きさになってしまいます（A4、4枚位）。

　ユースケースシナリオを記述していると、足りないユースケース、概念のブレや漏れを発見できます。また、システムの振る舞いが見えてきます。

　このユースケースにはまだ足りないものがありますが、このプロジェクトは実験プロジェクトですので、それはレビューの時まで触れないでおきましょう。

　また、ユースケースシナリオの作成と並行して更新していった、概念モデルとユースケースモデルを示します。

　概念モデルは、概念の数が増えました。ユーザーとシステムの振る舞いを叙述的に検討していった結果、足りない概念を抽出することができました。

　ユースケースモデルは、新たにひとつ、ユースケースを発見しました。これも、ユースケースシナリオを書いたお陰です。

　ひとつのことを、視点を変えて考えることは、網羅性を維持する上で大変重要なことです。正直、私自身この作業（ユースケースシナリオ）が一番面倒ですが、その苦労は成果に確実に出ますので、やり抜いてください。現に、これまでのモデルを眺めると、システムの動作イメージや、設計時の考慮点などが浮かんでくるはずです。

　ちなみに、ユースケースシナリオを今回のようにモデル化すれば、ユースケースモデルをあえて最終成果物とする必要ないでしょう。ただし、ユースケースシナリオにアクターを追加することをお忘れなく。

続く…

Open Knowledge System(4)

　前回のユースケースモデルと画面スケッチについて、疑問を感じた方がいるのではないでしょうか？　まず、画面スケッチをもう一度見てみましょう。

　この図は、「Knowledge参照画面は、概念モデルKnowledgeに、依存する」と読むことができますが、画面と概念が不一致しています。これは整合がとれていない、と指摘されて当然のことですが、なぜ、整合がとれていないことを簡単に認識できたのでしょうか？

　それは、画面と概念、およびその関係をこのモデルによって認識できたからです。ひと言でいえば、これがRDRAのパワーです。「もの、こと」の関係に着目することで要件を開発していこうとするRDRAのパワーを、「おかしい」と思った方は体験したことになります。

　モデル間の不整合は、それを気づいた時に修正すればよいでしょう。

　次に、ユースケースモデルですが、これは要求モデルと整合しているのでしょうか？　図による関係線でこれを検証しても良いのですが、Enterprise Architectには関係マトリックスという便利な機能があります。

　これによって、要求とユースケースの関連性を図のようにチェックすることができます。要求にないユースケース（図の薄い青色背景色に対応するユースケース）がありますが、これは基本的に問題ありません。逆は、大変大きな問題になることはいうまでもないことです。

続く…

Open Knowledge System(3)

　前回までで、コンテキストモデル、要求モデル、業務シナリオ、概念モデルを作成しました。RDRAではこの後、業務フローモデル、利用シーンモデルを作成するのですが、業務シナリオを見ると、フローよりもシーン、私の言葉でいうとフローよりもストック系の業務が大部分のように見えるので、業務は業務シナリオで把握できたという仮説のもと、ユースケースモデルの作成に移りたいと思います。ユースケースを考える中で、必要があれば業務モデルに戻ることにしましょう。

　業務シナリオを見ながら、ユーザーとシステムとの接点をユースケースとして表し、その関係性をprecedesとinvokesで表現します（ユースケースの関係表現は、ICONIXプロセスに基づいています）。また、ユースケースのアクターも関係線により明記しておくのがよいでしょう。

　次は、ユースケースシナリオを記述します。人によっては、随分と冗長な作業をするなぁ、と感じるかもしれませんが、これは、ひとつのことを違う視点で考察することにより、分析の品質を上げることができるためです。例えば、図で表現したことを文章にしてみることで、気づきが生じることがあると思います。
　＊冗長な作業…とは、業務フローモデル、利用シーンモデルを作成した上で、さらにユースケースシナリオを詳細に記述することを前提とした表現です。本文だけでは言葉足らずと気づき、加筆しました。なお、私が定義している要件開発時のライフサイクルについては、こちらを参照してください。

　しかし、ユースケースシナリオをより良く作り上げるために、私は画面イメージをスケッチしたくなりました。

　このように、概念モデルと対比させるような形でスケッチすると良いでしょう。また、HTML対応という「設計」をこの段階に持ち込むことには異論のある方もいると思いますが、私はICONIXの予備設計という概念を参考に、要件開発に設計の要素を適度に加えることにしています。また、要件開発の前工程であるVP（情報化構想立案）やSP（システム企画）では、既にシステム アーキテクチャーの概要が検討されているはずですので、これを考慮した要件開発には正当性があります。言い方を変えると、設計や実装をまったく考慮しない要件開発は現実的ではないと私は思います。

続く…

Open Knowledge System(2)

　今日は次期基幹システムのデータ移行作業の日です。私の主な役割は不測の事態に備えた待機ですので、何事もなければ溜まった仕事をかなり片付けられるはずです。
　昨日から作業を始めたOpen Knowledgeが気になったので、脳を活性化する意味で、昨日作ったモデルを投稿することから始めたいと思います。

　前回は、Open Knowledgeのコンテキストモデルを掲載しました。次は、Open Knowledgeの価値である要求モデルを作成します。

　今の段階では、思いつくままに、つまり要望レベルで列挙すればいいと思います。RDRAの思想に則り、できるところから広く浅く作業を進め、広く浅くを積み重ねることによって、十分な要件が開発できればよいという訳です。
　
　＊要望、要求、要件の定義

• 要望　：　アイデア、思いつき
• 要求　：　要望の内、問題解決に必要なもの。
• 要件　：　要求の内、システムに実装するもの。

　Open Knowledgeのように小さなシステムでは、要望の一つひとつがそのままユースケースになりそうな感じです。

　次は、Open Knowledgeを使った業務の姿を業務シナリオでスケッチしてみます。これは、業務モデルを作るための事前作業と私は考えています。

　スケッチですのでこんな感じでちょうど良いのではないでしょうか？　既に、要求モデルにはない要求が盛り込まれていますが、これは後で要求モデルに反映させていきます。このように、静的な機能を想像して作った要求モデルと、動的な動きを想像して作った業務シナリオのふたつにより、あるべきシステムの価値を把握することができます。

　コンテキストモデル、要求モデル、業務シナリオの三つによって、Open Knowledgeのアウトラインが表れてきました。次は、Open Knowledgeの概念を整理しましょう。

　knowledgeという概念だけは、属性まで記述してみました。そのことが、今後の作業に重要だと考えたからです。他の概念については、今の段階で属性を気にすることはないでしょう。
　テキストと添付ファイルの概念は、knowledgeの属性と重複しますが、まあ、今の段階ではこのままにしてみましょう。モデリングに対する私の姿勢は、気になるのなら残しておけということです。不用なものを取るのは簡単ですが、ないものに気づくのは難しいからです。
　概念モデルができたら、これまでのモデルの言葉を概念モデルに合わせましょう。

　分析時に気をつけなければいけないことは、厳密にモデリングし過ぎることです。次の概念モデルはその例です。

　これは明らかな過剰分析です。いわゆる分析の罠、分析地獄です。要件開発の段階で、このような細かい概念を必要とすることはないでしょう。

続く…

Open Knowledge System

　ブログを始めたことによって、このような仕組みを組織内で日常的に活用したら、いろいろな用途に役立つだろうと考えるようになりました。
　一方、流麗なシステム開発の上流工程を考えていると、とにかく実践がしたくなります。もちろん、会社では仕事として上流工程を行っていますが、もっと自由に、好き勝手にトライしたいのです。となると、プライベートなシステム開発のテーマが欲しくなります。
　以上から、Open Knowledgeというシステムを考えました。ずばり、Wikipediaのパクリです。

　Open Knowledgeを開発する目的は、システム開発の方法論に関する実験検証と、どうせ作るのなら役に立つものを、というふたつです。

　ブログがそうであるように、経験、思想、知識等をオープンにすることには意味があります。しかし、今回の開発目的からするとブログは規模が大きく思えるので、簡易的なWikipediaがいいだろうという結論にいたったのです。

　＊この段階で、VP（情報化構想立案）、SP（システム企画） の2工程が終了しました。予算とスケジュールはOpen Knowledgeにはありません。システム開発のライフサイクルについては、「流麗な上流工程の研究（メモ）」の「ライフサイクルとWBS」を参照してください。

　Open Knowledgeの開発過程は、随時、本ブログで紹介していく予定ですが、本日は要件開発工程に入ったOpen Knowledgeのコンテキストモデルをご紹介します。 
　御覧のように、非常にシンプルです。 knowledgeという概念を含めているのは、Knowledgeが問題領域の中心であり、その取り扱い方法を規定するのがOpen Knowledgeというシステムであることを明確にするためです。
　目的には、「完成したOpen Knowledgeが果たすべきこと」が記述されています。開発手法の実験という目的は、いうまでもなく「完成したOpen Knowledgeが果たすべきこと」ではありません。
 
続く…

コンテキストモデル（カスタマイズ版）

　RDRAのコンテキストモデルのカスタマイズ例を書いてみました。

　以前、小さな要件開発や新たな仕事舞い込むで示したように、フルスペックのRDRAモデルが必要ではない小規模な要件開発では、下図のように要点をひとつのモデルに集約し、全体を俯瞰しながら業務を進めることが効果的です。

 

　モデリングの技法などには囚われず、まずは自分自身が理解するための道具としての活用が第1段階。他者とのコミュニケーションを円滑にするのが第2段階。そうしたアプローチの中で、表記法などの統一を図るなど、組織内の標準化を進めてもいいかもしれません。
いずれにしても、問題領域を「捉えて、理解して、コミュニケーションする」ための自分に合う道具を見つけることが重要です。



関連記事
性質変換によるデスクワークの工場化
ソフトウェアの開発プロセスについて
Open Knowledge System
流麗な上流工程の研究（メモ）
コンテキストモデル（カスタマイズ版）
流麗なシステム開発の上流工程を実現するために
小さな要件開発
システム開発の要件定義に関する考察
要件開発の進め方～私のRDRA運用法～
RDRA(2) - RDRAとの出会い
RDRA

RDRA

　私は絶えずいくつかの仕事を並行して行っていますが、その内のひとつが新システムの要件開発です。この新システムでは、プロポーザル方式で複数社から提案を受けることにしていますので、要件開発に基づくRFPの作成までが主たる私の業務となります。
　今回の要件開発にあたっては、リレーションシップ駆動要件分析RDRA（ラドラ、Relationship driven requirement analysis）という手法を採り入れました。これは次期基幹システムでの苦い経験を基に、上流工程のあり方を自分なりに再構築する中で、RDRAに関する書籍に出会い、感銘し、これを要件開発の核になる方法論として組み入れようと考えたからです。
　これまでの知識経験とRDRAを組み合わせることにより、新たな要件開発方法論を手に入れた私は、6月からこの方法論による要件開発を進めています。進捗としては、9割弱まで開発が進んだかな、というところです。
　新しい試みですので、当然試行錯誤がありますが、中でもモデリングを効率的に行うことに最も試行錯誤しています。
　モデリングツールには、Enterprise Architectを使用していますが、モデルの規模が大きくなるにつれて、全体を効率よく整合させていく作業に工夫が必要になります。これは、私のツールに対する熟練度もあるでしょうが、モデルを描くディスプレイの大きさや紙の大きさなど、いくつかの制約の中でモデリングを進めるためには、私のみならず工夫がいるのではないかと考えています。
　そんな試行錯誤も、いずれ紹介できればと思うのですが、要件定義に悩みを抱え、RDRAをご存じないのであれば、是非一度RDRAを勉強してみてください。

関連記事
性質変換によるデスクワークの工場化
ソフトウェアの開発プロセスについて
Open Knowledge System
流麗な上流工程の研究（メモ）
コンテキストモデル（カスタマイズ版）
流麗なシステム開発の上流工程を実現するために
小さな要件開発
システム開発の要件定義に関する考察
要件開発の進め方～私のRDRA運用法～
RDRA(2) - RDRAとの出会い
RDRA