astahによるUMLモデリング

2017/05/05

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」を気軽に読んでいたら、ブルックスの人月の神話の一節が書かれていて、今頃になって、すごく腑に落ちたのでメモ。
ブルックスの人月の神話の文章のうち、自分が理解できたことを、ラフなメモ書き。
以下は書きかけ。

【参考】
第0回:人月の神話とはなんなのか?(解説編)|本気で読み解く”人月の神話” | GiXo Ltd.

第2回:銀の弾は無いけど、”銃”はあるよね|本気で読み解く”人月の神話”(第16章) | GiXo Ltd.

ソフトウェア開発とは、現実世界の複雑さをプログラムコードの難しさに置き換える作業だ - セカイノカタチ

ソフトウェア開発でよく言われる「銀の弾丸など無い」とはどういう意味なのか本を読んでみた。 - 感謝のプログラミング 10000時間

【1】ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の内容自体は10年以上前のWebやIT業界の話が多く、内容も古くなっているので、新たな知見が得られるという感覚はしない。
しかし、「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の中に、「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」という言葉があって、すごくしびれた。

(引用開始)
ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。
したがって、複雑性を取り去ったソフトウェアの実体の記述は、しばしばその本質も取り去ることになる。
数学や物理学は、複雑な現象を単純化したモデルを構成し、そのモデルからある性質を引き出し、実験的にその性質を証明することで、3世紀にわたって偉大な進歩を遂げた。
この方法でうまくいったのは、モデルで無視された複雑性が現象の本質的な性質ではなかったからだ。
複雑性が本質である場合には、この方法は使えない。
(引用終了)

上記の内容は、ブルックスの「人月の神話」の一節そのまま。
なぜ自分がすごく衝撃を受けたのか、考えてみると、ソフトウェア開発の本質に触れているものだから。
たぶん、僕の心のなかにある、ソフトウェアに対する楽しさだけでなく、ソフトウェアへの憎しみというか、なぜこう思い通りにソフトウェア開発をコントロール出来ないのか、という腹立たしさに触れている気がしたから。

「偶有的」という言葉も引っかかる。
この言葉は、古代ギリシャのアリストテレスの哲学から引用したものらしい。

(引用開始)
アリストテレスに従って、難しさを本質的なものと偶有的なものに分けて考えてみよう。
ここで、本質的な複雑さとは、ソフトウェアの性質に固有な困難のことであり、偶有的難しさとは、目下の生産にはつきまとうが本来備わっているものではない困難のことである。
(引用終了)

自然科学、特に数学や物理学では、できるだけ単純なモデルを作り、そこから演繹される性質や定理を証明することで、自然現象を多面的に分析しようとする。
複雑なものを複雑なまま捉えるのではなく、理想的な単純なモデルに純粋化して、人間の思考に耐えられるレベルにして、数多くの観点で徹底的に分析するのが自然科学のやり方。
シンプルなモデルを「徹底的に」分析し尽くして、全ての特徴を洗い出し、全てを因果関係や演繹でまとめ上げて一つの理論体系にするのが自然科学のやり方。

すると、シンプルなモデルをどのように事前設定するか、どのパラメータを重視して選択しておくか、というのが重要になる。
その部分が、科学者の腕の見せ所。

たとえば、物理学では、理想気体みたいに、現実から離れるけれど、シンプルなモデルを設定することで、計算や実験を扱いやすくするモデル作りは一般的だ。
熱力学、相対性理論、量子力学など、色んな分野の物理学でもその手法を用いている。

物理学は一つの認識論: プログラマの思索

数学でも、一流の数学者は、自分で理論を打ち立てたい時、最も組合せの少ない公理や公準を直感的に選んで、そこから矛盾が生じないように設定しておく。
そこから、「誰々の定理」のような重要な結果を導き出す。
一流の数学者がすごいのは、最も組合せの少ない公理を直感的に把握できること、そして、重要な定理を導く時に、ロジックの穴になりそうな難しい場所を事前に察知して、それをくぐり抜けるために、あらかじめ「誰々の補題」みたいな補助的な公式を用意しておくのが上手い点。

技術の背後に数学の理論があると廃れない: プログラマの思索

数学や物理は背景にある思想を知らなければ理解できない: プログラマの思索

このやり方がすごく成果を上げているので、人文科学や社会科学でもそのやり方を真似ているように思える。
特に、経済学は典型的だろう。
マクロ経済学やミクロ経済学みたいに、人間は合理的に行動する、とか、市場の価格は恣意的な手段で決めても長続きせず、神の手(つまりは市場原理)で決まる、みたいに、現実とかけ離れた仮定をおいて、数多くの経済モデルを作り、そこから重要な経済学の定理を導き出す。
単純な経済モデルから得られた経済学の定理で現実に通用する場面が過去にあったから、経済のグローバル化が世間に言われ始めてから、世の中の経済事象は、市場原理で決まる、いや決めるべきだ、みたいな論調が多い気がする。

経済数学の直観的方法の感想: プログラマの思索

「推計学のすすめ」「経済数学の直観的方法~確率統計編」の感想: プログラマの思索

しかし、ブルックスの「人月の神話」では、ソフトウェアにはそのやり方が通用しない、という指摘をしている。
「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」からだ。
つまり、複雑性を排除したソフトウェアは、ソフトウェアの本質を意味しないからだ。

【2】ソフトウェアの本質的な複雑さと、偶有的な複雑さの違いは何か?
ソフトウェアの本質的な複雑さは、リーマンの法則そのものを指すと思う。

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

リーマンの第1法則
 使われるシステムは変化する。
リーマンの第2法則
 進化するシステムは複雑性を減らす取り組みをしない限り、システムの複雑性が増す。
リーマンの第3法則
 システムの進化はフィードバックプロセスによって決まる。

(引用開始)
レーマンとベラディは、大規模なオペレーティングシステムのリリースについて、継続してその変遷を研究してきた。
そこで分かったことは、モジュールの総数はリリース番号とともに線形に増加するのに対し、影響を受けるモジュールの数はリリース番号に対し指数的に増加するということだ。
(中略)
システムプログラムの作成は、エントロピーを減らす仮定だから、本来は準安定なものである。
他方、プログラムメンテナンスはエントロピーが増加する過程であり、どんなに器用に行なっても、できるのはシステムが修正不能な陳腐化へと沈んでいくのを遅らせることだけである。
(引用終了)

(引用開始)
ソフトウェア製品開発に関する古典的問題の多くは、その本質的な複雑性と、ソフトウェアの大きさに従ってその複雑性が非線形に増大することに由来している。
(引用終了)

この文章を読んで思い出すのは、ケント・ベックがXPを生み出した経緯のことだ。
ケント・ベックは、ソフトウェア工学の授業で習った、リリース総数が増大するにつれてソフトウェアの複雑度や変更コストが増大していく経験則に対して、異議を唱えた。
時間が進むに連れて、この曲線を頭打ちにできるような開発プロセスはないのか、と。

- eXtreme Programmingの魅力を探る オブジェクト倶楽部

(引用開始)
「変化ヲ抱擁セヨ」
この呪文めいた言葉は,Kent Beck による本の副題として掲げられている. 時間を横軸に,ソフトウェアの変更にかかるコストを縦軸にプロットする.
この「時間-変更コスト」曲線は極端な右上がりになると信じられて来た(図左).
すなわち,要求分析,設計,実装,テスト,保守,と時間が進むにつれ, 変更にかかるコストが増大するというのだ.
現在までのソフトウェア開発プロセスは,この仮定上の議論が多数 だったのである.
XP はこの曲線を平坦にできるのではないか, また,そうできたとしたら,全く違った方針でプロジェクトに立ち 向かえるのではないか,という挑戦をしている(図右)
(引用終了)

こういう素朴な問題意識はすごく重要だと思う。
XPがその理想を本当に実現したのかどうか、は検証がいると思うが、そういう背景を元にアジャイル開発のプラクティスが生まれたことは、アジャイル開発が従来のソフトウェア工学と対立しがちに見える傾向を示唆しているように思える。

ちなみに、上記の第1版の「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法」に、上記の「従来のソフトウェア工学が提唱しているソフトウェア複雑性へのXPの果敢な挑戦」の文章と図はあるのに、第2版の「エクストリームプログラミング」から削られていることだ。
とても残念。
この部分がXPにとって一番重要な主張なのに。

【3】コードクローンと再利用性。

(引用開始)
ソフトウェア実体の本質とは、データセットやデータ項目間の関係、アルゴリズムや機能呼び出しなどが組み合わさったコンセプトで構成されたものである。
この本質は、同じ概念構造体が多くの異なる表現で表されるという点で抽象的である。
それにもかかわらず、非常に正確で十分に詳細なものである。
(引用終了)

コードクローンとは、同一アルゴリズムを各プログラマが別々の実装したプログラムのことだ。
上記は、ソフトウェアの複雑性が増大しがちな理由の一つは、コードクローンが大量に発生しがちである、と言う点を示唆していると思う。

ソフトウェア工学の論文を見ていると、コードクローンのメトリクス採取の記事が割と多い。
その理由は、コードクローンを減らす方がソフトウェアの複雑性が減るので、良い、という主張が隠れているのではないか。

では、なぜコードクローンは良くないのか?

(引用開始)
ソフトウェア実体は、どの2つの部分をとっても似ることがないので、大きさの割にはおそらく他のどの人工構造物よりも複雑なものだ。
似通っている部分があれば、2つの類似部分を1つにする。
この点において、ソフトウェアシステムは、重複要素(部品)が豊富なコンピュータやビルあるいは自動車などとは全く異なっている。
(引用終了)

その理由は、ソフトウェアの再利用が進まないからだ。
たとえば、自動車やパソコン、スマートフォンのような工業製品は、再利用可能な汎用部品を組み立てる手法と大量生産することを組合せることで、規模の経済を生かし、経験曲線効果を生かして、1個当りの製造コストを劇的に減らす。
しかし、この「規模の経済」「経験曲線効果」というコストメリットを享受しうる生産手法がソフトウェア開発には全くといっていいほど通用しない。

ソフトウェアを部品化して、スマートフォンみたいに部品を組み立てるように製造したい、と考えて、CORBAとかEJBのようなコンポーネント駆動開発、製品ファミリー群の製品開発手法であるソフトウェアプロダクトラインとか色々考えられたけれど、どれも実用的ではない。

ソフトウェア部品化の幻想: プログラマの思索

ソフトウェアプロダクトラインが解決しようとするもの~品質と再利用: プログラマの思索

だから、多額の資金を設備投資に投入して、最新の機械で汎用部品を組合せて大量生産する生産手法がソフトウェア開発には馴染まない。
ソフトウェア開発は徹頭徹尾、経験曲線効果すらも有効でない労働集約的な生産手法に似ているように思える。

【4】ソフトウェアの本質的な複雑性とは、同調性、可変性、不可視性。

【4-1】同調性は、リーマンの言う組み込まれた(Embeded)プログラム、を連想する。

「ソフトウェア・グラフィティ」の感想: プログラマの思索

(引用開始)
支配しなければならない複雑性の多くは気まぐれによるものだ。
インターフェイスを人間の社会制度やシステムに適合させるべく、いわば是非もなくそれらによって強制されているからである。
(引用終了)

最近、業務システムとかERPに僕自身が少し興味をなくしているのは、システム化したい業務そのものが元々複雑過ぎて、それを整理しようと言うよりも、現実の業務をいかに忠実にシステム化するかに注力する案件の方が多いからだ。
元々の業務が、日本的な複雑な組織体制を元に作られていれば、複雑なのは当たり前であり、それを忠実にシステム化するなら、複雑怪奇なままだ。
日本では、ERPをBPRとして捉えるよりも、自分達の業務中心に考えすぎているために、システムも複雑怪奇になりやすいような気がしている。

【4-2】可変性は、ソフトウェア品質の移植性や保守性を連想する。

アジャイル開発が重視する品質特性~保守性と移植性: プログラマの思索

(引用開始)
ソフトウェア実体は、つねに変更という圧力にさらされている。
(引用終了)

XPの言う「変化を抱擁せよ」と同じ。
ソフトウェアにとって、VerUpは宿命であり、常に変化が内在している。
ソフトウェアは変化しない固体として存在し得ない。

(引用開始)
純粋な思考の産物であってきわめて融通性に富んでいるので、ソフトウェアがより簡単に変更できるということもある。
ビルも現実には変更されるものだが、だれもが了解しているように、変更コストの高さが思いつきで変更しようとする者の気をくじく働きをしている。
(引用終了)

ソフトウェアに、仕様変更という名の保守はつきものだ。
それは簡単にできるように思えるから、簡単にソフトウェアに手を入れて、潜在バクを埋め込んでしまう。
ソフトウェア品質特性のうちの保守性を連想させる。

(引用開始)
大当たりしたソフトウェアはまずたいてい、すべて変更される。
あるソフトウェア製品が役立つと分かると、人々はもともと処理対象としていた領域ぎりぎりもしくはその領域を越えるような新しい使い方を試してみようとする。
主として、拡張機能のために変更して欲しいという圧力は、基本機能が気に入っていて新しい使い方を考えだす利用者から出される。
(引用終了)

これは、たとえば、Redmineが当初のバグ管理の使い方から、タスク管理、そして、アジャイル開発やWF型開発、さらには、事務処理ワークフロー、ハードウェア資産管理システムへ使い道がどんどん広がっていった事例を連想させる。
本来想定しなかった使い方が一般的になってしまい、その使い方をさらに使いやすくしたり、機能改善することで、ソフトウェアの複雑性がどんどん膨張する。
あらゆるソフトウェアは機能追加という変化にさらされている。

(引用開始)
大当たりしたソフトウェアは最初に書かれた対象である機械機器の通常の寿命よりも長く使用され続ける。
要するに、ソフトウェア製品はアプリケーションや利用者、慣習および機械機器といった文化的マトリックスにすっかりはめこまれているのだ。
そしてそれらは絶えず変化し続けるものであり、その経kながソフトウェア製品に容赦なく変更を強制するのである。
(引用終了)

たとえば、OSやDBやミドルウェアのバージョンアップとか。
あるいは、サーバー本体のリプレースとか。
たとえば、WindowsXP廃棄対応、WindowsServerのリプレース、OracleのVerUp、RailsのVerUpとか、iOSやAndroidOSのVerUpとか、色々思い出す。
つまり、ソフトウェア品質特性の移植性を連想させる。

こういうミドルウェアやOSのVerUpに伴うプログラム変更作業は、とてもしんどいものだ、と開発者なら誰でも知っている。
こういうつまらない開発基盤のVerUp作業は、ソフトウェアの外にある外部環境の変化によって生じるものであり、避けることは出来ない。

【4-3】不可視性は、ソフトウェア設計の難しさを連想する。

(引用開始)
ソフトウェアの構造を制限したり単純化したりすることは進歩したにもかかわらず、その構造は本質的に視覚化できないままになっている。
そのため強力な概念上のツールを作る意欲を阻害している。
その欠落は1人の人間の頭の中のデザインプロセスを妨げるばかりでなく、複数の人間の間でのコミュニケーションもひどく妨害する。
(引用終了)

UMLやDOAは、ソフトウェア構造を視覚化する問題を解決しようと試みていた。
SySMLもその流れだろう。

複雑性をコントロールするための設計技法は、歴史上いくつか考えれてきた。

たとえば、Nティア設計。
つまり、レイヤ化。

another level of indirection
「もう一段の間接参照」を導入すると、コンピュータのほとんどの問題は解決できる。

NFuji's Café: 「Beautiful Code」を読む(中)

ポインタを制する者はプログラミングを制する: プログラマの思索

MVCモデル、通信プロトコルの7層モデルもそういう考え方だろう。

他に、渡部幸三さんの観点でのDOAでは、業務・機能・データの3層構造の業務システムにおいて、業務レイヤとデータモデルのレイヤに複雑性を押しこんで、機能レイヤは複雑性をできるだけ減らす設計が良い、と提唱していた。
すなわち、機能レイヤはまさにプログラミングレベルなので、その部分の複雑性はできるだけ減らして保守性を高めようとする考え方。
つまり、複雑性というエントロピーは一定で変わらないと仮定した場合、人が携わる業務レイヤと、データモデルのレイヤに複雑性を落としこんで、複雑性をコントロールしようとするわけだ。

だが、これらの手法で、ソフトウェア本来の複雑性が本質的に解決されたのか、と問うてみると、正直分からない。

【5】一方、ソフトウェアの偶有的な複雑さは個別撃破している。

「高水準言語」は、たとえば、VBよりもRuby。
たとえば、VBはListやHashなどの基本ライブラリのAPIが非常に不足していて使いにくい。
たとえば、Rubyなら、そういう低レベルなライブラリは非常にAPIが揃っていて、VBよりも1行で書ける。
つまり、複雑性を軽減している。

「タイムシェアリング」は、たとえば、コンパイラ言語よりもインタプリタ言語、継続的ビルド管理、構成管理を指すのかな。

(引用開始)
考えていた内容をすっかりというわけではないが些細な点でどうしても忘れてしまう。
(引用終了)

この部分は、まさにソース管理、構成管理を連想させる。
たとえば、CVS、Subversion、Gitに至るまでの構成管理ツールの歴史を振り返れば、ソフトウェア開発プロセスにおけるブランチ管理、マージなどの作業の複雑性は軽減されている。

「統一されたプログラミング環境」はたとえば、VisualStudioやEclipse、IntelliJとか。

つまり、ソフトウェアを開発する作業そのものが生じる複雑性は、今までの歴史で生み出された技術によって、多少は軽減されてきた。
しかし、だからと言って、ソフトウェアの本質的な複雑性を攻略できたわけではない。
あくまでも、以前よりも大きい複雑なソフトウェアをコントロールできるようになった、というだけだ。

| | コメント (0)

2017/02/23

データフローダイアグラムではプロセスは一番最後に書く

データフローダイアグラムの書き方について、良い記事があったのでリンクしておく。
記事を読んで、まだ修行が足りないと感じたので、自分用のメモ。

【参考1】
データフローダイアグラムの書き方

(引用開始)
プロセス,データの発生源・行き先,データの保管元・保管先全てに名前がついているにもかかわらず,データの流れにだけ名前がついていないDFDを見かけることがあります.
これらはDFDの役割を果たしていません.
DFDが表現しなければならないのは,プロセス,データの発生源・行き先,データの保管元・保管先を行き来するデータなのです.
データの流れに名前をつけないのは,DFDが最も表現しなければならないものを表現していないということです.

図6.プロセス名は最後につける
(引用終了)

(引用開始)
入出力するデータからプロセスの内容の推測が困難な場合,原因はプロセスの機能分割が適切ではないことが多々あります.
プロセスは,例え名前がなくても,入出力データからその内容を容易に推測できるものでなくてはなりません.

データの流れに名前をつける際には,「~情報」や「~データ」と言う名前をつけてはいけません.
抽象的すぎ何を表わしているのかわかりません.
図6の営業所からのデータの流れの名前が「販売実績」ではなく「営業所情報」や「販売情報」だったら,何を表わしているのかわかるでしょうか.
もし,データの流れに具体的な名前がつけられないのなら,DFDの作り方に間違いがあります.再検討しましょう.
(引用終了)

【参考2】
DFD(データフローダイヤグラム)の描き方(1) | ステキな一日

(引用開始)
仕事でDFDを書く機会が多いのだが、DFDの書き方を知らない人が多いのでここにメモしておく。
自分自身が100%完璧に使いこなしているわけではないので、自分の理解している範囲での内容となる。

データフローダイヤグラム(DFD)は単独で成り立つものではありません。
データディクショナリーとミニ仕様書という三点セットで業務分析を行う際に使用します。
システムの概念だけを伝えるのであれば、DFD単体でも良いのかも知れませんが・・・。
(引用終了)

DFD(データフローダイヤグラム)の描き方(2) | ステキな一日

(引用開始)
さて、DFDの描き方です。一番初めに何を描きますか?

(1)今回の対象外となるものをすべて描き出します。
これは外部要素となるものです。それは取引先だったり、外部システムだったりします。

(2)そして外部要素への入出力を描きます。(これは対象外への最終的な入出力となります。)

(3)データフロー名は必ず書くようにしてください。
プロセス名を入れたいかも知れませんがプロセス名は無くても大丈夫です。(後で入れられるし、変わるかもしれないので)

(4)今度はデータフローをよく見ていきます。
足りないデータフローがたくさんあるはずですから、図にどんどんデータフローを足していきます。
また、データフローが変換されるところや複数に分岐するところにはプロセスも足していきます。
そうやってどんどん書き足していくと、データを保管する所も見えてきますのでデータストアも書き足していきます。
そうやって、描き替えながらユーザとどんどん対話してください。
(引用終了)

DFD(データフローダイヤグラム)の描き方(3) | ステキな一日

(引用開始)
DFDを書くうえで一番重要なのがデータフローの名前の付け方です。
データフロー名の付け方によってDFDの分かりやすさはかなり違ってきます。
ここが一番肝心かなめのところですから手を抜かないようにしてください。

プロセスに名前を付ける段階ではデータフローのすべてに名前が付いてなければいけません。
はじめにプロセスに名前を付けたいかもしれませんが、ぐっと我慢をしてください。
プロセスに最後に名前を付けるのは、データフローを正しく書くために必要です。
(中略)
プロセスに先に名前を付けてしまうと、DFDを書けてしまった気になって肝心のデータフローがおろそかになったり、分析が足らなかったりしますので、注意してください。
(中略)
エクセルの図形で描いてもいいのですが、それでは書き直しが面倒になってきて、かなり出来の悪いDFDしか書けないと思いますのであまりおすすめできません。
それよりは手書きの方がマシだし、それともVISIOでも良いです。 
個人的にいちばんおすすめなのが astah* professional というソフトウェアです。
(引用終了)

DFD(データフローダイヤグラム)の描き方(4) | ステキな一日

(引用開始)
DFDにセットで必要になるものがあります。それがデータディクショナリーとミニ仕様書です。

データディクショナリーには、データフローの内訳を記述します。
そして、ミニ仕様書にはプロセスの内容を記述します。DFD、データディクショナリー、ミニ仕様書が揃ってひと塊となります。
どれが欠けても中途半端です。
(中略)
しかしながら、これもまた、DFD、データディクショナリー、ミニ仕様書を行ったり来たりしながら、ブラッシュアップさせていくものです。
(引用終了)

DFD(データフローダイヤグラム)は業務システム設計でよく使うけれど、何故か描きにくい、と思う時が多かった。
缶アイコンのデータストアは書けるのだが、プロセスがイマイチしっくりこない時が多い。
上記の記事を読んで、プロセスを最初に書いてしまうので、それに引きずられて、本来のモデルが描けなくなっているのではないか、と気づいた。

「プロセスの名前は一番最後に書く」。
つまり、外部要素やデータフローをじっくり書き込んで、漏れを無くし、整合性を取った後で、最後にプロセスの名前を書けばよい。
DOAでは、データが主であり、プロセスは従の立場だから。
プロセスは最後に名前付けすることで、データの入出力やタイミングに集中して分析できるようになる。

これから気をつけようと思う。

| | コメント (0)

2016/04/24

豆蔵ソフト工学ラボのモデリング記事のリンク

豆蔵ソフト工学ラボのモデリング記事がいつも参考になるので、リンクをメモ。
自分が考えていることをラフなメモ書き。

【参考1】
誤解しがちなモデリングの技:目次 | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第1回:コンポジションにまつわるアレコレ | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第2回:隠れた曖昧さ | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第3回:ステートマシン図(I) | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第4回:ステートマシン図 (II) | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第5回:ユースケース図にまつわるアレコレ | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第6回:初心者にありがちな間違い | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第7回:モデルの意味的な誤り(I) | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第8回:モデルの意味的な誤り(II) | 豆蔵ソフト工学ラボ

【参考2】
組込み開発のためのモデリングワンポイントレッスン:目次 | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン:第1回:対象を明確に | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン:第2回:デバイスのモデリング | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン:第3回:クラスとインスタンスの区別 | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン:第4回:ドメインと制御の区別(前編) | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン:第5回:ドメインと制御の区別(後編) | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン:第6回:状態って何? | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン:第7回:イベントいろいろ | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン:第8回:状態遷移 | 豆蔵ソフト工学ラボ

【1】一つのシステム、一つの業務を分析する時、複数の観点でモデルを描いて、重要な箇所やキーとなる部分を把握したい時にUMLは役立つと思う。
但し、いくつかの注意点があると思う。

業務システム、業務の設計では、UMLの観点の分析は役立つが、ER図とDFDがやはり必要。
ER図で帳票の項目がどのように配置されるか分かるし、DFDで業務フローとデータの関連が一瞥できる。

個人的に注意している点は、エンティティがイベント・リソースだけでなく、サマリテーブルとして保持すべき部分はどこであるか、という所。
リアルタイムに表示したい時に時間がかかるならば、バッチ処理で集計したデータをサマリテーブルに生成し、そのデータを表示させるように設計する。
すると、その表示のタイミングによって、データは最新でないから、ユーザが戸惑う時がある。

また、業務システムのモデリングでも、組込システムと同様に、データのライフサイクルという観点で状態遷移図を考えたい時があるが、ER図・DFDではそれを表現しにくい。
いつもしっくりこない。

【2】組込システムのモデリングでは、UMLの観点の分析はすごく役立つと思う。
クラス図で必要な処理がオブジェクトに集約されるし、シーケンス図やアクティビティ図でオブジェクトの動的な処理をプログラムとほぼ一致させることもできる。

個人的に注意している点は、組込みシステムを状態遷移図として表現する時に、複雑な要件や仕様をどこまで状態遷移図で表現できるか、という所。
システムを状態遷移図に表現できれば、事実上、プログラムに自動生成することは可能。
だが、実際のシステムでは、イベントを待っていて発火する、とか、イベントの履歴を保持してどの状態に遷移させるべきか使用が決まっている、とか、色んなパターンがあって、状態遷移図に全ての仕様を盛り込むのも難しい。

UML2.xの状態遷移図の仕様を調べると、かなり複雑な仕様を表現する事はできる。
「H」のような履歴というモデル要素などを考えてみると、過去の人達が苦労して編み出した概念なんだな、とか分かる。

また、組込み開発のためのモデリングワンポイントレッスン:第4回:ドメインと制御の区別(前編) | 豆蔵ソフト工学ラボの記事のように、ドメインと制御の部分を区別して設計するのもかなりに熟練の業を必要とすると思う。
ユーザ側の観点ではドメインの要素しか見ないが、実際のシステム内部では、たくさんの制御装置があって、それら装置が連動して整合性が取れて初めて、システムが正常動作する。
ドメインと制御装置の依存関係、制御装置同士の関係を表現するのが難しいと思う。
どうしても、Controller部分が肥大化してしまうので、Mediatorパターンのように表現したくなるが、何となくいつもうまくいかない気がする。

【3】豆蔵さんの上記の記事はどれもとてもよく考えられている記事なので、astahでUMLをモデリングしていて、何となくしっくり来ない時に読み直している。
自分も、モデリングのパターンを整理してみたいと思う。

| | コメント (0)

2016/04/05

Enterprise Architectの使い方のリンクとメモ

古い記事だが、Enterprise Architectの使い方のリンクがあったのでメモ。

IT設計で使っているツール:気になっていることのメモ:So-netブログ

Enterprise Architect(EA)をこのように使ってます。その1:気になっていることのメモ:So-netブログ

Enterprise Architect(EA)をこのように使ってます。その2:気になっていることのメモ:So-netブログ

Enterprise Architect(EA)をこのように使ってます。その3:気になっていることのメモ:So-netブログ

Enterprise Architect(EA)をこのように使ってます。その4:気になっていることのメモ:So-netブログ

Enterprise Architect(EA)をこのように使ってます。その5:気になっていることのメモ:So-netブログ

Enterprise Architect(EA)をこのように使ってます。その6:気になっていることのメモ:So-netブログ

Enterprise Architect(EA)はこんな事もできる:気になっていることのメモ:So-netブログ

ドキュメントを作成する時に:気になっていることのメモ:So-netブログ

スパークスシステムズジャパン フォーラム - ユーザー掲示板 CRUD図の表の中身の逆生成は可能ですか?

UML再考: プログラマの思索

日本でモデリングツールが使われない背景: プログラマの思索

EnterpriseArchitectはとても多機能なモデリングツール。
僕はまだ使いこなせてない。

上記の記事では、EAの使い方としてUMLにこだわらず、要求→ユースケース→機能→テストケースまでのラフな絵を描いて想像を膨らませたり、要求→ユースケース→機能→テストケースまでのラフな絵を階層化した構造ツリーを表示することで変更要求の影響箇所を一瞥できるのが便利だ、と述べている。
その点は、EAに限らず同感だ。

モデリングツールはastahをずっと使い続けているが、モデリングツールに期待する機能はたくさんある。
ステートマシン図から状態遷移表を自動生成したり、機能(ユースケース、プロセス)とテーブル(ER図)を組合せたCRUD表の自動生成、とか。
状態遷移表は組込みシステムのイベントフロー設計で使えるし、デシジョンテーブルのテストケースとしても流用できる。
CRUD表は、サブシステムの分割基準に使えたり、FP法による簡易見積りにも使えるだろう。

また、クラス図、アクティビティ図、ステートマシン図、ER図、DFDなどあらゆるダイアグラム間で、整合性を担保したり、トレーサビリティを維持する仕組みは、モデリングツールで自動チェックしてくれなければ実現は不可能。
最終的にはモデリングツールでモデルのトレーサビリティを保証することで、要件や仕様の漏れをなくしたいのだ。

つまり、モデリングツールを使いこなせれば、見積り・設計・テストの作業効率化に適用できるはず。

設計ツール | system-enablers日記にはこんな文章がある。

(引用開始)
また、有用なツールは、開発手法も教えてくれます。
例えば、今現在、注目しているICONIXプロセスではEAを使うことを推奨していて、EA用のアドインを提供しています。
(中略)
「プロは腕も持っているが、道具も持っている」ものです。
わたしたちもプロの道具を上手に使って、いい仕事をしたいものです。
(引用終了)

個人的には、関西でastahを使ったモデリングの勉強会を開いて、情報共有したいなあと思ったりする。

| | コメント (0)

2015/08/25

「ビヨンド ソフトウェア アーキテクチャ」は買い?

ビヨンド ソフトウェア アーキテクチャ」がもうすぐ販売されるのでメモ。
興味がそそられる。

【参考】
ビヨンド ソフトウェア アーキテクチャ(LukeHohmann 岡澤裕二 和智右桂) | 翔泳社の本

おおお『Beyond Software Architecture』訳されたのか! これはとても良い本でした。 - t-wada のコメント / はてなブックマーク


(引用開始)
「アーキテクチャ」について技術的な観点から書かれている本は数多くありますが、ビジネスの視点からシステムを商品として見た時に考えるべきことを教えてくれる本が、実はありませんでした。
本書は、アーキテクチャにおけるビジネス(マーキテクチャ)と技術(ターキテクチャ)をつなぐ架け橋として、情報システム部の方全員に読んでほしい本(情シス必読書)です。
エンジニアにとっては、マーケティングの基礎を学ぶ上でも役に立ち、かつ、技術面でのアーキテクチャ論としても、経験豊富な著者の実体験に根ざす優れた考察に富んだ一冊となっています。

原書は2003年にMartin Fowlerシグネチャシリーズの一冊として刊行されました。Jim Highsmith、Mary Poppendieck、Ed Yordon、Craig Larman他から多数の賛辞が寄せられています。著者のLuke HohmannはOOPSLAやUML Worldの常連スピーカーとして、QUALCOMMなどを経て現在はConteneo,Inc.のCEOに就いていますが、それ以前には全米フィギュアスケート選手権のジュニアチャンピオンでもあった異色の存在でもあります。

最後に、訳者より一言「情シスの方はアジャイルやスクラムもよいですけど、こういうアーキテクチャのこともきちんと考えてみませんか?」
(引用終了)

(引用開始)
目次

第1章ソフトウェアアーキテクチャ
第2章プロダクト開発入門
第3章マーケテクチャとターキテクチャ
第4章ビジネスとライセンスモデルの共益関係
第5章インライセンステクノロジー
第6章可搬性
第7章デプロイメントアーキテクチャ
第8章統合と拡張
第9章ブランドとブランド要素
第10章ユーザビリティ
第11章インストール
第12章アップグレード
第13章コンフィギュレーション
第14章ログ
第15章リリース管理
第16章セキュリティ
補遺A:リリースチェックリスト
補遺B:戦略的プロダクトマネジメントのためのパターン言語
(引用終了)

本棚を見返すと、和智さんの翻訳本はほとんど購入している。
エリック・エヴァンスのドメイン駆動設計」「組織パターン」「エッセンシャル スクラム」「実践テスト駆動開発」然り。
どれも分厚くて、何度も読み直して咀嚼し直すたびに、新しい発見がある。

今度の本もすごく楽しみだ。

翻訳された本の分野を見ると、アーキテクチャ設計やアジャイル開発にフォーカスされている。
僕が興味を持っている分野にドンピシャリだなと思ったりする。

ビヨンド ソフトウェア アーキテクチャ」でググってみると、下記のPDFが見つかる。
目次がそっくりなのだが、関係あるのかな?

/ - alimnova - Grupo de trabajo ingenieria de software - Google Project Hosting

| | コメント (0)

2015/08/18

ユースケース駆動ではなくロバストネス駆動開発?

「ロバストネス駆動開発」という言葉を見つけたので思わずメモ。

【参考1】
天使やカイザーと呼ばれて ≫ ロバストネス駆動開発?

天使やカイザーと呼ばれて ≫ ロバストネス図113枚!!

OOAD講座:第5回「ロバストネス分析を設計・実装につなげる」 | artisan edge thinking

ロバストネス図の使い道: プログラマの思索

ユースケース→ロバストネス分析→クラス設計という順に開発していくスタイル。
この時、ロバストネス分析が最も重要であるという認識から、「ロバストネス駆動開発」とネーミングしたらしい。
確かに、ロバストネス図がきちんと書ければ、バウンダリ・コントローラ・エンティティを多少変形するだけで実装に近いクラス図を設計できる。

ロバストネス図を1日中書いたら113枚になった、という記事は確かにすごい。
単なるテーブル保守画面ではなく、背後に複雑なロジックがあったり、バッチ処理があったりすると、ラフな設計がいるのだろう。

【参考2】
ソフトウェア開発の匠(1):「ITエンジニアは職人気質を取り戻すべき」 (2/3) - @IT

ソフトウェア開発の匠(1):「ITエンジニアは職人気質を取り戻すべき」 (3/3) - @IT

ユースケースの疑問: プログラマの思索

UML再考: プログラマの思索

ユースケースの善し悪し: プログラマの思索

でも、萩本さんの記事によれば、「ロバストネス分析に多大な工数をかけたが成果が出ない」という問題もある。

(引用開始)
ロバストネス分析から、シーケンス図などを使って動作検証を図り、分析モデルを作り上げる作業までには多くの工数を要した。
しかし、その結果作成された分析モデルは設計モデルにつながりにくく、何のためにシーケンス図などを使って検証したのか、作成したエンジニアたちにも分からなかった。

(1)ユーザーも開発者も理解しづらい産物を作りかねない
(2)分析モデルを作るまでに多くの工数を要する
(引用終了)

オブジェクト指向分析(OOA)の弱点は、分析モデルと実装モデルの乖離があるために、実装モデルに辿り着くまでの工数が大きくかかることだろう。
分析麻痺症候群に陥りやすい弱点があるのではないか。

概念モデル→論理モデル→物理モデルみたいな流れだと、中間成果物がやたらと増える。
しかもその成果物の保守も大変。

ロバストネス図がユースケースとクラス図の間を結ぶミッシングリンクであることは分かるが、仕様変更やソース修正と同じタイミングでロバストネス図も保守していくのは結構大変だ。
つまり、ロバストネス図も設計書やソースと同じく、構成管理の配下に置くべきである。
しかし、構成管理と連動したモデリングツールは結構使いづらい。

但し、astahは個人的には設計のスケッチツールとして使いやすいし、Subversionと連携して構成管理も可能だ。

【3】ロバストネス駆動開発は、個人的には結構イケているのではないか、と思ったりする。
簡単に書けるし、書いていくうちに、処理の粒度に気づいたり、他の人とのコミュニケーションにすぐに使えるからだ。

もう少し考えてみる。

| | コメント (0)

2015/08/14

ユースケースの善し悪し

ユースケースの善し悪しについて、良い記事があったのでメモ。

【参考】
良いユースケースを書くための発想法

ユースケースの疑問: プログラマの思索

ロバストネス図の使い道: プログラマの思索

ユースケース駆動開発実践ガイド: プログラマの思索

ユースケース駆動開発実践ガイドを読んでわかったこと - paz3のおもいつき

ユースケース駆動開発実践ガイドを読んでわかったこと、その2 - paz3のおもいつき

最近、ユースケース記述を読む機会があり、システム要件がシンプルに上手く書かれていた。
その理由を考えている時、良いユースケースを書くための発想法を読んで、なるほどと思った。

僕もよく間違えるけれど、ユースケースを機能仕様としてシステム観点で細かく書いしまいがち。
本来のユースケースは、利用者の観点で、システムスコープを明確にすることだ。
また、ユースケースは、利用者とシステムの相互作用の観点として書かれるべきなので、シーケンス図でシステムと応答するような形で書くイメージになるべき。

| | コメント (0)

2015/07/21

UMLの概念モデルで法律を理解するアイデア

UMLのモデルで法律を理解するアイデアをメモ。

【参考】
UMLモデリングレッスン - サポートページ

第1回 編集者ガチンコバトル、お勧めモデリング本! | Think IT(シンクイット)

【1】「UMLモデリングレッスン」のレッスン50に、刑法の犯罪要件について、UMLのクラス図で概念モデルを描いている事例がある。
このクラス図を見ながら、刑法の条文を読むと、ああなるほど、と何となく腑に落ちた。

【1-1】上記では、「刑罰法規が犯罪構成要件を規定する」「~という行為が犯罪構成要件に該当する」という文言がそのままクラスとその関連名に当てはまる。
犯罪になる行為として、「違法行為」「非違法行為」の2種類があり、非違法行為になる条件として「違法性阻却事由」を持つことが当てはまる。

つまり、刑法の条文はとても冗長な文章であるが、その本質となる文章をそのままクラスと関連名に当てはめれば、概念モデルになりうる。
これは面白い。
おそらく理系の人は、こういう法律の文章はとても苦手だと思うので、こういうやり方で理解する方法もあるのかもしれない。

【1-2】上記の概念モデルをER図としてRDBに落とし込んだ場合、どのようなテーブル構成になるか?
僕の勝手な憶測では、下記のようになるだろう。
IDEF1Xで書けば、「●---」の向きで外部キーによる参照制約、「△---」の向きで派生関係を表す。

刑罰法規マスタ●---犯罪構成要件マスタ
行為トランザクション---●犯罪構成要件マスタ
(※但し、行為テーブルには、複数個の犯罪構成要件マスタを外部キーとして持てる)

行為トランザクション△---違法行為トランザクション、非違法行為トランザクション
非違法行為トランザクション---●違法性除却理由マスタ

UIとしては、行為データを登録・検索する画面と各マスタ保守画面がいるかな。
帳票としては、ある期間の行為データを印刷する帳票がいるかな。

【1-3】また、「UMLモデリングレッスン」を読んで興味深い部分は、上記のようなモデリング技法が、ソフトウェア開発で使われる場面が意外にあることだ。

例えば、上記のような概念モデルを用いて、政府や裁判所の要請に基づき、犯罪履歴や事例を検索したり保守するシステムを作る案件はもちろんありうる。

似たような例として、電力・ガス・電話などの事業会社やクレジットカード・保険会社の契約条文をビジネスルールとしてソフトウェアシステムに実装する場合がある。
これらの会社では、ビジネスの基本的な約束事は約款として定められており、そのビジネスルールがシステムの要件や制約に反映されるからだ。

例えば、クレジットカード会社や携帯電話会社では、カードやスマフォの契約時に、違法性がないか、ビジネスルールを課しており、そのルールを満たす人だけが契約できる。
そしてその契約情報は記録され、後から検索したり、契約延長や契約破棄などの保守ができるように、システムを作る必要がある。

そう考えると、携帯電話会社や銀行・カード会社と契約を結んだ時に約款として渡される大量の資料の背後には、彼らの会社の基幹システムにはビジネスルールとして実装されているのだろうと推測できる。

【2】この発想を推し進めれば、例えば、日本の特許庁のシステムリプレースでも、こういう概念モデルが必要だったのだろうと勝手に推測する。
実際のニュースを見ると、破綻した理由は他にもあるみたいだが。

News & Trend - 2012年の特許庁システム開発中止、開発費全額返納のなぜ:ITpro

【ITブラック】特許庁システムにまつわる黒い話が色々ヤバイ - NAVER まとめ

UMLのモデリング技法を用いて、ビジネスルールを概念モデルで表してみる手法は今後考えてみたい。

| | コメント (0)

2015/04/25

astahプラグインのタスク一覧が良い感じ

astahプラグインのタスク一覧が良い感じなのでメモ。

【参考】
astah*プラグイン タスク一覧(拡張タブビュー表示) 0.9.1公開 | 響雲

ノートに「TODO」と書いておけば、下部にTODOリスト一覧が表示される。
EclipseのTODOタグと同じ機能。
TODOリスト一覧をダブルクリックすると、TODOが記載されているダイアグラムが開くのもいい。

モデリングは1回では終わらない。
TODOを残しながら、1つずつ解決して描いていく時が多いから、重宝しそう。

| | コメント (0)

2015/01/25

さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーの感想 #RDRAセミナー

さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーに行ってきた。
要件定義の考え方がすごく参考になった。
感想をラフなメモ書き。

【元ネタ】
さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナー - アジャイルウェア | Doorkeeper

要件構造の見える化 #RDRAセミナー: ソフトウェアさかば

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索

【1】要件定義の問題。
いつまで経っても、システムの全体像が見えない。
大量のドキュメントばかりで、肝心のシステムが説明されない。
分析と言う名の転記作業ばかりで、要件定義が完了しない。

では、どうすればいい?

要件定義、要件分析では、個人作業は非効率。
レビューと修正反映の繰返しでは、要件定義書の品質は上がらない。

その場で皆で合意を積み上げて進める方がいい。
ステークホルダーの合意のベースを作る方が重要。

議論を積み重ねる時に、使われる手法として、リレーションシップ駆動要件分析RDRAがある。

リレーションシップ駆動要件分析RDRAでは、要件定義書の元ネタとしてモデルを作る。
その時、システムよりも、システムを取り巻く環境に注目する。

システムは、エンジニアがこだわりがち。
その中身の説明は、最終的にはプログラムであり、ユーザは理解しにくい。
エンジニアの立場では、システムの設計は自力で何とかなる。

しかし、システムを取り巻く環境の方が要件定義では重要。
先に、システムを取り巻く環境から、要件を先に固める。
いかにプログラムレスで表現して、エンジニアがユーザと会話できるようにするか?

【2】リレーションシップ駆動要件分析RDRAの構造は、「システムの価値」「システムの外部環境」「システム境界」「システム(内部)」の4つ。

【2-1】システムの価値は、例えば、システムリプレースでは語られない時が多い。
AsIsは分かるが、ToBeが分からない。
ユーザから見れば、既に動いているシステムが要件そのもの、と言うが、実際は何のために作ったのか、その理由や背景が忘れ去られている。

【2-2】システム外部環境は、業務フロー、概念モデル(または用語集)、利用シーンから成る。
利用シーンは、業務フローがない場合に使う。
例えば、初めて作るユーティリティツールのように、まだ実際のシステムがない場合に、そのシステムがどのように使われるのか、という利用状況を描き出す。
業務フローがない場合、誰がどう使うのか、というイメージが湧きにくい。

利用シーンは、ユースケースとは違う。
ユースケースは、アクターとシステムの相互作用を表すから、システム境界に含まれる。
利用シーンは、システムを使って何が嬉しいのか、を表す。
利用シーンは、ユースケースが何故存在するのか、という理由や根拠になる。

【2-3】システム境界は、UIのような画面・帳票、外部I/Fのような外部システム連携などがある。

【2-4】リレーションシップ駆動要件分析RDRAは、モデル同士のリレーションに注目する。
リレーションシップ駆動要件分析RDRAでは、モデル同士の依存関係を表したい、という目的がある。

問題意識としては、混乱している要件定義フェーズを収束させたい。
その鍵は、モデルの依存関係にある。

よくある問題は、いきなり機能一覧を洗い出すものの、要件が発散してしまうこと。
特にリプレース案件で多い。
現状のシステムから、機能一覧はすぐに洗い出せるが、それだけでは要件定義は終わらない。

何故、その機能やデータがいるのか?
AsIsではなく、本来のあるべきシステム像は何なのか?
例えば、昔は汎用機やCobol、10年前はVBでガリガリ作られたデスクトップアプリだったろうが、現代では、クラウドの上のWebシステムや、工場でも作業者がタブレットを持って歩きまわるように実現すべきではないか?
AsIsの要件にひきずられると、高い費用を払ったのに、昔と変わり映えしないシステムになってしまい、ユーザにとって価値がない。

まずは、システムそのものではなく、システム境界を定めよう。
システムのスコープは何か?
システムとユーザのインターフェイスは何か?

システム境界の話で要件定義がまとまらないなら、システム外部環境に話を移そう。
どんな業務フローでシステムが必要なのか?
どんな利用シーンでシステムが使われると嬉しいのか?

それでも駄目なら、システムの価値を探ろう。
なぜ、システムは必要なのか?
誰にとって、システムは必要なのか?

「システムの価値」「システムの外部環境」「システム境界」「システム(内部)」という4つの視点が重要。
でも文章では分かりにくい。
だから、図ないしモデルで描こう。

但し、リレーションシップ駆動要件分析RDRAで描いたモデルは、ユーザ向け資料の元ネタであり、ユーザ向け資料は別途作成する必要がある。

【3】Q.価値を考える人とシステムを考える人は別々になりがちだが、リレーションシップ駆動要件分析RDRAではどのように対応すべきか?

価値を考える人=ユーザ、ドメインエキスパート。
システムを考える人=アーキテクト、エンジニア。

あるいは、価値を考える人=元請けSE。
システムを考える人=下請けPG。
日本のIT業界では、多段階下請構造によって、要件定義とシステム開発の工程が分断されがち。

A.攻め方が違う。
初めての新規システム案件なら、システムの価値→システムの外部環境→システム境界→システムのようにブレイクダウンしていく。

リプレース案件なら、AsIsのシステムがあるから、システム境界(or システム)→システム外部環境→システムの価値のように、リバースエンジニアリングしてシステムの構造やシステム境界を明確にしてから、システムの価値を探っていく。
リプレース案件では、機能一覧は普通にあるはずなので、そこからシステムの価値へ登っていく。

どちらにせよ、4つの観点のブレイクダウンやボトムアップで双方向に行き来する。

【4】コンテキストモデルでは、アクターとしてステークホルダーを洗い出す。
要求モデルでは、アクターの要求を洗い出す。

お金の権限を持つステークホルダーとその要求を洗い出せているか?

業務フローは作業フローではない。
業務フローは、普通、システムに大きく依存する。
作業フローは不要。
担当者の作業はコロコロ変わるから。
ロールや業務を洗い出したい。

ユースケースは機能分割しない。
ユースケースは機能ではない。
リレーションシップ駆動要件分析RDRAにおける「機能」とは、パッケージ製品のカタログの機能一覧の項目と同じレベル。
例えば、MSWordなら、こんな機能があります、というイメージ。

イベントモデルは2種類ある。
例えば、GoogleMapsのように、1回のやり取りでデータが確定するもの。
それは、機能モデルで表現できる。

一方、外部システムとのバッチ連携のように、データを何度もやり取りする場合がある。
それは、プロトコルモデルで、状態遷移図として表す。
イベントが発生したら、次の状態へ移る、という内容をプロトコルモデルで表す。

【5】リレーションシップ駆動要件分析RDRAでは、モデルをEnterprise Architectで描きます。

設計開発を強力に支援するUMLモデリングツール Enterprise Architect 概要と特徴

Enterprise Architectの良さは、設計情報がリポジトリに格納されるので、モデルの関連付けが自動付与されること。
また、モデルを描けば、設計リポジトリから機能一覧をすぐに出力できる。
機能一覧を元に、ユーザにヒヤリングして、要件を深堀りできる。

さらに、依存関係が不十分なモデルがある場合、クエリを使って設計リポジトリから対象モデルをすぐに検索できる。
要件定義レビューの前に、担当者にモデルを修正するように作業指示も出せる。

他に、Enterprise Architectはリバースエンジニアリングが強い。
JavaやC#だけでなく、RubyやActionScriptなどの軽量言語もサポートしているのが強み。

Enterprise Architectで、現状のシステムのソースを全部読み込み、クラス同士の関連をリバースエンジニアリングした後、モデルを整理していけば、システムの構造が見えてくる。
そこから、システム境界、システムの外部環境、システムの価値を探っていく。

【6】リレーションシップ駆動要件分析RDRAで作成したモデルでは、網羅性と整合性の根拠を説明できる利点がある。

アクター→要求→利用シーン→ユースケース→画面→機能→データ のように関連付けていくので、なぜその機能やデータが必要なのか、という根拠を説明することはできる。
つまり、ある要求に基づく画面や機能が網羅されているか、という根拠を説明はできるだろう。

また、モデルの整合性は、モデル同士のリレーション、依存関係で語れる。
例えば、機能一覧にあるこの機能は、このユースケースを実現したものであり、それはこの設計書に書かれている、など。

要件定義では、要件の網羅性、要件の整合性を語ることができれば、ステークホルダーを説得することができる。


【7】要件定義プロセスはタイムボックスで作業すると良い。
つまり、イテレーションごとに、要件定義を進めていく。

最初のイテレーションでは、荒い粒度のモデルしか作れないが、速く作れる。
3回ぐらいのイテレーションで、まずはシステムの全体像を把握できる。

その後のイテレーションで、モデル同士のリレーションを正しく書いていく。

つまり、前半のイテレーションでは、システムの全体像をつかむために速く成果物を作り、後半のイテレーションで成果物の品質を向上させていく。
すなわち、前半は漸進型開発、後半は反復型開発に切り替える。

【7-1】お客様は大量の成果物を好む。
詳細は見ないけれど。
お客様は根拠を聞きたがる。

お客様の打合せに合わせて、イテレーションを組み立てる。
お客様の打合せに合わせて、資料を作り、ブラッシュアップしていく。

まず、システム地図や機能一覧を作る。
そして、詳細を詰めていく。

マイルストーン(イテレーションの区切り)の単位で、成果物の範囲を決める。
そうすれば、要件定義が成果物の転記作業の繰返しにはならない。

【7-2】Q.リレーションシップ駆動要件分析RDRAでは、システムの実現可能性はどこで行うのか?

A.リレーションシップ駆動要件分析RDRAでは、要件定義とアーキテクチャの話を分けている。

・要件定義フェーズでアーキテクチャ設計は並行して行うが、要件定義とアーキテクチャ設計は別チームで行う

・要件定義チームから非機能要求を渡し、アーキテクチャチームでアーキテクチャ候補を返す

・二つのチームは手段で話をせずに非機能要求で話をする。

・後付けでもいいので「非機能要求があってアーキテクチャがある」という形は崩さないことが重要。そうすればアーキテクチャ決定の根拠が明確になる

要件定義チームとアーキテクトチームに分けた理由は何か?
アーキテクトが要件定義チームに入ると、ブレーキをかけがち。
例えば、その要件は、現在採用しているフレームワークやアーキテクチャでは実現できませんよ、とか。
あるいは、リプレース案件では、AsIsのアーキテクチャに引きずられて、ToBeのアーキテクチャを考えにくくなる。

【8】今日は、システム地図を書きます。
システム地図とは、アクター、ユースケース、画面、機能、データ、外部システムなどの項目を関連付けて、システムの全体像を表したもの。
システム地図は数時間で書ける。

RDRAのモデルは種類が多いので、丸一日かかる。
だから、今日はシステム地図を書きます。

【8-1】僕達のチームで作ったシステム地図はコチラ。
@spring_kumaさんのおかげで、かなり品質の高い成果物が作れたと思う。
@spring_kumaさんに感謝。

【9】システム地図を書いた感想:
僕の感想と、発表後に聴衆の方からあがった質問も書いておく。

【9-1】利用シーンとユースケースの使い分けが難しい。
混乱した。

利用シーンは、システムを使って嬉しいこと。
利用シーンは、ユースケースの根拠になる。
なぜ、そのユースケースは必要なのか、その理由は、こんな利用シーンが必要だったから、と。

【8-2】ユースケースは出しやすい。
ユースケースはアクターとシステムのインターフェイスになるから。

ユースケースは普通は画面で実現される。
つまり、ユーザがシステムとやり取りするI/Fが画面だから。
そして、画面のボタンが「機能(Function)」になる。

【8-3】要求が結びつくアイコンは?
それはアクターまたは利用シーン。

機能に要求を結びつけても説明しにくい。
モデルが複雑になる。

【8-4】メール送信や決済代行システムのモデルが表現しにくい。
バッチ処理で描こうとして、上手く書けない。
僕らのチームは、画面から予約ボタンを押したら、予約確認メールが飛ぶような仕組みで表現して逃げた。

神崎さんの回答は、バッチかどうかはアーキテクチャの話。
要件定義では、アーキテクチャの話は不要であり、システムと機能やデータがどのように関連付けられているか、が分かれば十分。

【8-5】システム地図を描く利点は、自分たちが弱い部分が判明するのが良い。
例えば、決済代行システムの部分が描きにくい、など。

システム地図が描きにくい部分のモデルを特定できれば、ユーザのヒヤリングをその部分に集中することで、ヒヤリングの精度を上げることができる。
不明点に重点を置いてヒヤリングすればいい。

【8-6】システムの地図の粒度は?

粒度はケースバイケース。
イテレーションごとに詳細化していく。
最初から細かく書く必要はない。

最初のイテレーションでは粗い粒度で、システム地図を描き、システムの全体像を把握し、自分たちの弱点を見出す。
その後のイテレーションで、ユーザにヒヤリングしながら、モデルを詳細化していけばいい。

【8-7】他チームのシステム地図で面白かった点は、利用シーンから考えたので、良い議論ができた、ということ。
例えば、貸会議室.comのお題は、利用者と貸主のマッチングサイトを作ること。

その利用シーンとして、貸主が空いている貸会議室を登録するだけでなく、貸会議室.comでは儲からないから、貸し会議室.comから貸会議室を予約取り消しする機能が必要だね、という議論があったらしい。
僕達のチームでは、そんな発想は出なかった。

つまり、利用シーンを元に、メンバー同士で議論していたら、そんな機能が必要である可能性まで深く議論できたことになる。

【8-8】貸会議室.comのお題というリッチピクチャがあったから、システム地図が描きやすい。
実際の要件定義では、貸会議室.comのお題のようなリッチピクチャは存在しない。
真っ白な所から、システム地図を描き出す必要がある。
要件定義は、そういうもの。

【9】リレーションシップ駆動要件分析RDRAの全体感想:

モデルベース要件定義テクニック―要件定義書がスラスラ作れる」を読んでいたから、4つの観点やモデルは理解していたが、実際の話を聞いてかなり理解できた。
神崎さんの話を聞くと、要件定義でよくある失敗を踏まえたノウハウがたくさん散りばめられている。

【9-1】要件定義フェーズでは、少人数の担当者が限られた期間で要件を収集し、ステークホルダーの合意を得て、要件を確定しなければならないプレッシャーがある。
また、作成した要件定義書は、その後の設計・開発フェーズの元ネタになるので、開発チームにとって非常に重要だ。

例えば、要件定義書で既に要件が漏れていたら、開発チームは対処できない。
受入テストになって初めて、要件漏れが発覚して、デスマーチになりがち。

あるいは、システムの価値は要件定義フェーズでしか得られない。
要件定義フェーズでシステムの価値を明確に定義できなければ、開発チームは、システムの価値を気にせず、ひたすら作ることだけに集中してしまいがち。
受入テストになって初めて、ユーザからこんなシステムが欲しいのではなかった、と言われる。
でも、開発チームにとって、そんなことを言われても、自分たちの責任ではないよ、と言いたくなる。

【9-2】リレーションシップ駆動要件分析RDRAのポイントは、二つあると思う。

一つ目は、モデル同士の依存関係に着目することで、要件の網羅性や整合性の根拠を説明しやすくなること。
ユーザからの質問や要件定義ビューで、要件の網羅性や整合性の根拠を語ることが出来れば、スムーズに要件分析できる。

2つ目は、要件定義もアジャイル開発のようなタイムボックス型の作業にすることで、要件定義の成果物をブラッシュアップしやすくなること。
最初から完璧な要件定義書を作るのではなく、イテレーションに応じて、粒度を変えて、詳細化するタイミングを設定すればいい。
例えば、2ヶ月間で要件定義を終わらせるならば、1週間毎にユーザヒヤリングの場を設けてマイルストーン化し、最初はシステム地図で全体像を把握し、機能一覧を作り、詳細化していけばいい。

このテクニックを実際の現場でも使ってみようと思う。

| | コメント (0)

より以前の記事一覧