ほとんど独り言のような話なのでちとなんなのですが。
先日自分の BLOG でシステムに保守作業を通じての雑感を書いてたのですが、（http://
その折から考えていた事に
１）運用を意識した、もしくは最適化するソフトウェアの設計ってのはどういうものなんだんでしょう。
これは、最近の行った保守作業が、結局、開発者が最終的なメンテ作業を行う結果になったので、運用作業者と設計者が別々の場合、設計情報をどのような形で、どこまで伝えれば十分なのかと言う事がきっかけかな。通常は一番最後に考えるけど、本当は設計基準に持ってきた方がいいんじゃないって思うときも有ります。どちらかと言うと、この辺は設計が主で運用は従と言う気もします。あとは以前、社内で「メンテナンスフリーなソフトウェアって何で難しいんや」と管理職の人と大論争になった経験も影響しているかも知れない。結局、メンテナンスって何なの、なぜ発生するのって所で、物別れに終わったな。・・・
２）通常、システム設計において、変更可能な点（ホットスポット）を考える時、あくまで機能要求に対する変更容易性を中心に考えてそれをホットスポット等の概念で表現しますが、システム全体として考えた場合、扱うべきデータの性質（蓄積されるか、一時的かとか）や構成機器の寿命、システムに関係する人（アクタ）、もしくはアクタの要求する機能群の有効期限などから大域的に、変更点の種別・構成そして運用作業モデル、最適保守モデルを導き出すような、そんな設計アプローチって無いのかしら。当然、システムの機能要件、ユーザービリティを十分満たすと言う制約条件は言わずもがななんですが。
機械工学の関連で、人工物工学ってアプローチがありますが、考えとしてはそれに近いかもしれない。後は AIちっくに自律的なモジュールの集合体でシステムを組むアプローチかな。こっちはブラックボックスを考えないといけなくなるかもしれないのが、懸念か。
それとも、結局は CMM のようにプロセスや組織の最適化で考えるしかないのか。
さて、誰か時間のある人、興味を持った奇特な方がいればご意見よろしくお願いします。
先日自分の BLOG でシステムに保守作業を通じての雑感を書いてたのですが、（http://
その折から考えていた事に
１）運用を意識した、もしくは最適化するソフトウェアの設計ってのはどういうものなんだんでしょう。
これは、最近の行った保守作業が、結局、開発者が最終的なメンテ作業を行う結果になったので、運用作業者と設計者が別々の場合、設計情報をどのような形で、どこまで伝えれば十分なのかと言う事がきっかけかな。通常は一番最後に考えるけど、本当は設計基準に持ってきた方がいいんじゃないって思うときも有ります。どちらかと言うと、この辺は設計が主で運用は従と言う気もします。あとは以前、社内で「メンテナンスフリーなソフトウェアって何で難しいんや」と管理職の人と大論争になった経験も影響しているかも知れない。結局、メンテナンスって何なの、なぜ発生するのって所で、物別れに終わったな。・・・
２）通常、システム設計において、変更可能な点（ホットスポット）を考える時、あくまで機能要求に対する変更容易性を中心に考えてそれをホットスポット等の概念で表現しますが、システム全体として考えた場合、扱うべきデータの性質（蓄積されるか、一時的かとか）や構成機器の寿命、システムに関係する人（アクタ）、もしくはアクタの要求する機能群の有効期限などから大域的に、変更点の種別・構成そして運用作業モデル、最適保守モデルを導き出すような、そんな設計アプローチって無いのかしら。当然、システムの機能要件、ユーザービリティを十分満たすと言う制約条件は言わずもがななんですが。
機械工学の関連で、人工物工学ってアプローチがありますが、考えとしてはそれに近いかもしれない。後は AIちっくに自律的なモジュールの集合体でシステムを組むアプローチかな。こっちはブラックボックスを考えないといけなくなるかもしれないのが、懸念か。
それとも、結局は CMM のようにプロセスや組織の最適化で考えるしかないのか。
さて、誰か時間のある人、興味を持った奇特な方がいればご意見よろしくお願いします。
|
|
|
|
コメント(12)
独り言の続きです。
どんなだろう・・？(･･*)｡｡oＯ（想像図）
ハムレット>システム全体として考えた場合、扱うべきデータの性質（蓄積されるか、一時的かとか）や構成機器の寿命、システムに関係する人（アクタ）、もしくはアクタの要求する機能群の有効期限などから大域的に、変更点の種別・構成そして運用作業モデル、最適保守モデルを導き出すような、そんな設計アプローチって無いのかしら。
なんだかんだと言いながら、こんな事を考えている背景には、これから業務で取り組む上で、システムの安全性とかも考えないといけないかも知れない。 ISO14200 って機械システムにおける安全設計の国際規格があります（JIS 化されています。）対象は機械システムなのですが、内容はその中で使われるソフトウェア（制御系も情報系も）の品質にまで言及しています。この場合の安全性というのは、システムの運用字における安全性の確保です。ソフトウェアのエラーによる危険性の把握と、その防護対策みたいな事の必要性について書かれていたかな。まだ詳しく調べていないのですが、わりとドメイン非依存な汎用的な規格なので、これに準拠したソフトウェアの設計を考えると、
１）設計で品質を作りこんで、バグを潰していく。
２）最悪の事態を想定して、運用でカバーできるような仕掛けを作る。
１）は従来のソフトウェア工学で十二分に取り上げられてきただろうな。
２）についてはどうなんだろう。多分にもう少し汎用的なシステムの設計学って範疇だろうし、一番近い分野は人工物工学かなって思った次第。しかしこれもまだ調べていない事の方が多い。しかし
ハードウェア：主→ソフトウェア：従
って研究なら多いだろうが、
ソフトウェア主：→ハードウェア：従
って言うか、ソフトウェアの性質からハードウェアの有り方にまで提言している研究の方はどの程度あるのだろうか。自律的なロボットの制御アーキテクチャ関連の研究とかだったら、こんなスタイルなのかな。
あと、「構成機器の寿命」とかを中心に考えるなら、IBM が研究している Autonomic Computing （http://www-03.ibm.com/autonomic/index.shtml）があるか。これは、ハードウェア、ソフトウェアの両面からコンピュータの自律性を高めて、対障害性を上げる為の研究だったかな。面白そうだと思うが、まだ詳しく知らない。Autonomic Computing Toolkit なんて Java で走るツールキットも出しているが、これは ソフトウェアに自律性を持たせて、対障害性を実現するためのツールキットか。うーんなんか以前の別トピックでの話ではないが、アスペクトとか沢山使っていそうだな。
＃へんな空気を作って、突っ込みにくいってのは分かるんだが。・・・
＃さて、どうすれば良いのやら。;;;;（;・・)ゞｳｰﾝ
どんなだろう・・？(･･*)｡｡oＯ（想像図）
ハムレット>システム全体として考えた場合、扱うべきデータの性質（蓄積されるか、一時的かとか）や構成機器の寿命、システムに関係する人（アクタ）、もしくはアクタの要求する機能群の有効期限などから大域的に、変更点の種別・構成そして運用作業モデル、最適保守モデルを導き出すような、そんな設計アプローチって無いのかしら。
なんだかんだと言いながら、こんな事を考えている背景には、これから業務で取り組む上で、システムの安全性とかも考えないといけないかも知れない。 ISO14200 って機械システムにおける安全設計の国際規格があります（JIS 化されています。）対象は機械システムなのですが、内容はその中で使われるソフトウェア（制御系も情報系も）の品質にまで言及しています。この場合の安全性というのは、システムの運用字における安全性の確保です。ソフトウェアのエラーによる危険性の把握と、その防護対策みたいな事の必要性について書かれていたかな。まだ詳しく調べていないのですが、わりとドメイン非依存な汎用的な規格なので、これに準拠したソフトウェアの設計を考えると、
１）設計で品質を作りこんで、バグを潰していく。
２）最悪の事態を想定して、運用でカバーできるような仕掛けを作る。
１）は従来のソフトウェア工学で十二分に取り上げられてきただろうな。
２）についてはどうなんだろう。多分にもう少し汎用的なシステムの設計学って範疇だろうし、一番近い分野は人工物工学かなって思った次第。しかしこれもまだ調べていない事の方が多い。しかし
ハードウェア：主→ソフトウェア：従
って研究なら多いだろうが、
ソフトウェア主：→ハードウェア：従
って言うか、ソフトウェアの性質からハードウェアの有り方にまで提言している研究の方はどの程度あるのだろうか。自律的なロボットの制御アーキテクチャ関連の研究とかだったら、こんなスタイルなのかな。
あと、「構成機器の寿命」とかを中心に考えるなら、IBM が研究している Autonomic Computing （http://www-03.ibm.com/autonomic/index.shtml）があるか。これは、ハードウェア、ソフトウェアの両面からコンピュータの自律性を高めて、対障害性を上げる為の研究だったかな。面白そうだと思うが、まだ詳しく知らない。Autonomic Computing Toolkit なんて Java で走るツールキットも出しているが、これは ソフトウェアに自律性を持たせて、対障害性を実現するためのツールキットか。うーんなんか以前の別トピックでの話ではないが、アスペクトとか沢山使っていそうだな。
＃へんな空気を作って、突っ込みにくいってのは分かるんだが。・・・
＃さて、どうすれば良いのやら。;;;;（;・・)ゞｳｰﾝ
> ＃へんな空気を作って、突っ込みにくいってのは分かるんだが。・・・
> ＃さて、どうすれば良いのやら。;;;;（;・・)ゞｳｰﾝ
ソフトウェアの難しい問題がどばっと出てきてしまっていますね。
まず、細かいところから始めてもよかですか？
> これは、最近の行った保守作業が、結局、開発者が最終的なメンテ作業を行う結果になったので、運用作業者と設計者が別々の場合、設計情報をどのような形で、どこまで伝えれば十分なのかと言う事がきっかけかな。
開発者が保守作業者でもあるケースってどれくらいよくあることなんでしょうか？私は別々である場合を想定して研究を進めているのです。で、開発者が自分が保守をしないつもりならばどの程度の文書を保守作業のために残すのかなあ、と思いましてね。その後の人間への思いやりの相場は職場の有り方に依存すると思うのですが。
大学の人間は理屈は知っていても（いや、少なくとも私は大した理屈は知らないのですが）現場の事情を知らないもので…（いや、少なくとも私は[以下同様文]）
どうも本論と関係ないところですみませんね。
> ＃さて、どうすれば良いのやら。;;;;（;・・)ゞｳｰﾝ
ソフトウェアの難しい問題がどばっと出てきてしまっていますね。
まず、細かいところから始めてもよかですか？
> これは、最近の行った保守作業が、結局、開発者が最終的なメンテ作業を行う結果になったので、運用作業者と設計者が別々の場合、設計情報をどのような形で、どこまで伝えれば十分なのかと言う事がきっかけかな。
開発者が保守作業者でもあるケースってどれくらいよくあることなんでしょうか？私は別々である場合を想定して研究を進めているのです。で、開発者が自分が保守をしないつもりならばどの程度の文書を保守作業のために残すのかなあ、と思いましてね。その後の人間への思いやりの相場は職場の有り方に依存すると思うのですが。
大学の人間は理屈は知っていても（いや、少なくとも私は大した理屈は知らないのですが）現場の事情を知らないもので…（いや、少なくとも私は[以下同様文]）
どうも本論と関係ないところですみませんね。
どうもです。
hei, Izu-ruさん>ソフトウェアの難しい問題がどばっと出てきてしまっていますね。
hei, Izu-ruさん>まず、細かいところから始めてもよかですか？
はいな、よろしゅうお願いします。((ﾉ(_ _ ﾉ)
hei, Izu-ruさん> 開発者が保守作業者でもあるケースってどれくらいよくあることなんでしょうか？
少なくとも、ここに１ケースが。・・・
多分に大半のケースでは、保守と開発は別々だと思いますが、システムの性質上変ってくると思います。
hei, Izu-ruさん> 開発者が自分が保守をしないつもりならばどの程度の文書を保守作業のために残すのかなあ、と思いましてね。
そうですね。どこまで残せばええねんってのは、常々思うところです。外注さんも自分のところで開発していないシステムの保守はいやがるケースも多いです。残す文書は保守用の資料と同時に改良工事の元資料ともなる事も考えておく必要もあります。
以前 SIer が自治体向けシステムで１円とか１万円とかの安値受注を連発してたのが、新聞でも盛んに取り上げられていた時期があったと思います。あれも結局は保守の難しさを逆手にとって、メンテナンス費用で初期工事の赤字を埋めて、なお余る利益が見込めるが故という事情もあります。（公的機関の基幹業務系なんて止めるわけにも行かないので、抱え込んでしまえば相手の首根っこを押さえたも同然ですから。）
メンテナンスといっても、ちょっとした軽い作業から、新規工事同様の物までありますし。既存のシステムからの移行と事を考慮しないといけない分、かえって新規開発より難しい部分があります。（りファクタリングが注目されるのもこの辺の事情が根本にあると思います。）こうした理由から最近では保守とは言わずに、発展フェーズと呼ぼうという意見もあるようですね。
hei, Izu-ruさん>どうも本論と関係ないところですみませんね。
いえいえ、このコミュニティはバザールみたいにしたいと思うので、こうした書き込みはありがたく思います。
hei, Izu-ruさん>ソフトウェアの難しい問題がどばっと出てきてしまっていますね。
hei, Izu-ruさん>まず、細かいところから始めてもよかですか？
はいな、よろしゅうお願いします。((ﾉ(_ _ ﾉ)
hei, Izu-ruさん> 開発者が保守作業者でもあるケースってどれくらいよくあることなんでしょうか？
少なくとも、ここに１ケースが。・・・
多分に大半のケースでは、保守と開発は別々だと思いますが、システムの性質上変ってくると思います。
hei, Izu-ruさん> 開発者が自分が保守をしないつもりならばどの程度の文書を保守作業のために残すのかなあ、と思いましてね。
そうですね。どこまで残せばええねんってのは、常々思うところです。外注さんも自分のところで開発していないシステムの保守はいやがるケースも多いです。残す文書は保守用の資料と同時に改良工事の元資料ともなる事も考えておく必要もあります。
以前 SIer が自治体向けシステムで１円とか１万円とかの安値受注を連発してたのが、新聞でも盛んに取り上げられていた時期があったと思います。あれも結局は保守の難しさを逆手にとって、メンテナンス費用で初期工事の赤字を埋めて、なお余る利益が見込めるが故という事情もあります。（公的機関の基幹業務系なんて止めるわけにも行かないので、抱え込んでしまえば相手の首根っこを押さえたも同然ですから。）
メンテナンスといっても、ちょっとした軽い作業から、新規工事同様の物までありますし。既存のシステムからの移行と事を考慮しないといけない分、かえって新規開発より難しい部分があります。（りファクタリングが注目されるのもこの辺の事情が根本にあると思います。）こうした理由から最近では保守とは言わずに、発展フェーズと呼ぼうという意見もあるようですね。
hei, Izu-ruさん>どうも本論と関係ないところですみませんね。
いえいえ、このコミュニティはバザールみたいにしたいと思うので、こうした書き込みはありがたく思います。
えっと、つまみ食いのようなレスですが・・・
＞これは、最近の行った保守作業が、結局、開発者が最終的
＞なメンテ作業を行う結果になったので、運用作業者と設計者
＞が別々の場合、設計情報をどのような形で、どこまで伝えれ
＞ば十分なのかと言う事がきっかけかな。
この辺りの動機を同じくするものとして、Design Rationale という研究トピックがあります。直訳すると、「設計事由」といえばいいんでしょうか。要は、単なる設計書だけではなく「なんでこんな設計にしたの？」という設計者の意図をドキュメントに残しておこうという試みです。
たとえば(いい例かどうかわかりませんが）、あるウィンドウの大きさが何気なく設計書に書かれていたとしても、実はその大きさに重要な意図が隠されている場合もあります。それ以上の大きさだと、表示速度が極端に落ちるとか。見やすさと表示速度のトレードオフで、要求仕様に見合う一番よさそうな落としどころだったのかもしれません。
しかし、保守担当者や次期バージョンの開発者がそのことを知らないと、後々の顧客要求であっさり大きさを変更して、結果望まない影響を出したりするわけです。そういった事態を防ごうというのが背景としてあります。
洋書ですが、そのものズバリのタイトルの書籍がありますよ。
# ただ、実用に耐え得るかどうかはわかりませんが…
＞これは、最近の行った保守作業が、結局、開発者が最終的
＞なメンテ作業を行う結果になったので、運用作業者と設計者
＞が別々の場合、設計情報をどのような形で、どこまで伝えれ
＞ば十分なのかと言う事がきっかけかな。
この辺りの動機を同じくするものとして、Design Rationale という研究トピックがあります。直訳すると、「設計事由」といえばいいんでしょうか。要は、単なる設計書だけではなく「なんでこんな設計にしたの？」という設計者の意図をドキュメントに残しておこうという試みです。
たとえば(いい例かどうかわかりませんが）、あるウィンドウの大きさが何気なく設計書に書かれていたとしても、実はその大きさに重要な意図が隠されている場合もあります。それ以上の大きさだと、表示速度が極端に落ちるとか。見やすさと表示速度のトレードオフで、要求仕様に見合う一番よさそうな落としどころだったのかもしれません。
しかし、保守担当者や次期バージョンの開発者がそのことを知らないと、後々の顧客要求であっさり大きさを変更して、結果望まない影響を出したりするわけです。そういった事態を防ごうというのが背景としてあります。
洋書ですが、そのものズバリのタイトルの書籍がありますよ。
# ただ、実用に耐え得るかどうかはわかりませんが…
たけをさん>えっと、つまみ食いのようなレスですが・・・
いえいえ、要点を拾い上げて、又はポイントを絞ってと言う事でありがとうございます。
Design Rationale ですか。実は初耳です。確かに
システム分析 →＜機能要件以外の制約条件＞→システム設計
（幾つかの自由度がある。）
の流れの中で、機能要件以外の事も考慮に入れて設計を行っていくと、機能要件からみると自由度があるの中から、特定の条件を選択するといった作業になりますね。確かにこの辺は実装のノウハウや稼働環境、運用方針とソフトウェアプロセスの全ての過程に関わってきそうなので、設計文書の中でも自然言語でメモってのが、一般的ななのかな。確かに設計文書（例えば UML ）は設計の結果を示す物であって、途中の試行錯誤の中で
設計文書、 第一版 → ＜なんかの理由＞ → 第ニ版
の更新 （記録される） （メモ？） （記録される）
そんでもって、保守や改良工事でその＜なんかの理由＞が引っかかってしまう事は良くある話だと思います。
＃つい昨日も昨年開発したシステムで何でそんなフレームワークの構成したのかって、
＃説明をしていました。（理由は時間的な制約を満たすためだったのですが。）
＃こちらの意図を伝えきれていなかったら、改良工事のはずが単なるバージョンダウンになるところでした。(-。−；)
軽く調べてみると IDEF0（Activitiy Modeling 手法）でその辺を表現しようって流れも有るようですね。
いえいえ、要点を拾い上げて、又はポイントを絞ってと言う事でありがとうございます。
Design Rationale ですか。実は初耳です。確かに
システム分析 →＜機能要件以外の制約条件＞→システム設計
（幾つかの自由度がある。）
の流れの中で、機能要件以外の事も考慮に入れて設計を行っていくと、機能要件からみると自由度があるの中から、特定の条件を選択するといった作業になりますね。確かにこの辺は実装のノウハウや稼働環境、運用方針とソフトウェアプロセスの全ての過程に関わってきそうなので、設計文書の中でも自然言語でメモってのが、一般的ななのかな。確かに設計文書（例えば UML ）は設計の結果を示す物であって、途中の試行錯誤の中で
設計文書、 第一版 → ＜なんかの理由＞ → 第ニ版
の更新 （記録される） （メモ？） （記録される）
そんでもって、保守や改良工事でその＜なんかの理由＞が引っかかってしまう事は良くある話だと思います。
＃つい昨日も昨年開発したシステムで何でそんなフレームワークの構成したのかって、
＃説明をしていました。（理由は時間的な制約を満たすためだったのですが。）
＃こちらの意図を伝えきれていなかったら、改良工事のはずが単なるバージョンダウンになるところでした。(-。−；)
軽く調べてみると IDEF0（Activitiy Modeling 手法）でその辺を表現しようって流れも有るようですね。
Design Rationale の論文を最近目にしたような気がしたので探したのですが、見つかりませんでした。
その代わり昔こんな論文を読んだのでこれをご紹介いたします。
http://csdl.computer.org/comp/trans/ts/2001/01/e1toc.htm
の
pp. 58-93
Toward Reference Models for Requirements Traceability
Balasubramaniam Ramesh, Matthias Jarke
というのがこれです。なんか相当大掛かりなシステムなんですが、（というか多分これ軍事研究なんだと思いますが）要するに仕様を決定するに至った背景とか仮説とか当時の決定を知識ベース化して将来の仕様変更を考える際の参考にしよう、というものです。（と記憶しています）
状況が変わったら仕様策定時の仮説のどれを見直してその結果仕様のどの部分に影響が出て…いやあ、保守するのにこんなシステムが必要なソフトってやっぱり軍事システムくらいですかねえ。
なんか話が大げさになってしまいましたが、design rationale というものを極限まで推し進めるとこういう話になってしまうんじゃないかと思いましてご紹介する次第です。
その代わり昔こんな論文を読んだのでこれをご紹介いたします。
http://csdl.computer.org/comp/trans/ts/2001/01/e1toc.htm
の
pp. 58-93
Toward Reference Models for Requirements Traceability
Balasubramaniam Ramesh, Matthias Jarke
というのがこれです。なんか相当大掛かりなシステムなんですが、（というか多分これ軍事研究なんだと思いますが）要するに仕様を決定するに至った背景とか仮説とか当時の決定を知識ベース化して将来の仕様変更を考える際の参考にしよう、というものです。（と記憶しています）
状況が変わったら仕様策定時の仮説のどれを見直してその結果仕様のどの部分に影響が出て…いやあ、保守するのにこんなシステムが必要なソフトってやっぱり軍事システムくらいですかねえ。
なんか話が大げさになってしまいましたが、design rationale というものを極限まで推し進めるとこういう話になってしまうんじゃないかと思いましてご紹介する次第です。
＞なんか話が大げさになってしまいましたが、design rationale というものを極限まで推し進めるとこういう話になってしまうんじゃないかと思いましてご紹介する次第です。
いや、実際に Design Rationale を扱っている論文は知識工学的な背景を持つものが多いように思います。もともと、設計者同士の議論をグループウェア的に支援するとか(gIBISなど)、そういうところから来ているようですので。
ただのメモ的なものだと後から参照しづらいし、かといってキッチリ人手で書くのは設計者にかなりの負担になりますので、その間でどう効率化を図るか、というのが研究的には眼目なのでしょう。…が、現実的はちょっと「仰々しい」研究が多い気がします。
でもニーズは非常に同意できるところがあるので、lightweightなもので、うまく設計手法に織り込めるようなものがあるといいんでしょうねぇ。
いや、実際に Design Rationale を扱っている論文は知識工学的な背景を持つものが多いように思います。もともと、設計者同士の議論をグループウェア的に支援するとか(gIBISなど)、そういうところから来ているようですので。
ただのメモ的なものだと後から参照しづらいし、かといってキッチリ人手で書くのは設計者にかなりの負担になりますので、その間でどう効率化を図るか、というのが研究的には眼目なのでしょう。…が、現実的はちょっと「仰々しい」研究が多い気がします。
でもニーズは非常に同意できるところがあるので、lightweightなもので、うまく設計手法に織り込めるようなものがあるといいんでしょうねぇ。
どうもです。
ハムレット＞軽く調べてみると IDEF0（Activitiy Modeling 手法）でその辺を表現しようって流れも有るようですね。
たけをさん>これは存じませんでした。
軽く調べただけなので、何なのですが。IDEF は元々アメリカ空軍で機材の調達プロセスの効率化を動機に開発された業務プロセスの表現手法のようです。 0,1,3 とあって IDEF0 は添付した図にもあるように、Activity Modeling のための表記手法で、ちょうど DFD（Data Flow Diagram）に 制約条件と機構（コンテキスト？）を追加したような図になっています。UML には該当するような図はないんですが、制約条件と機構で Design Rationale を表現しようとしているのかな。（元ネタは http://www.jeel.co.jp/idef_ov.htm です。）
そう言えば IDEF0 ではこれに追加して、組織モデルの表記手法も持っており、それと連動させて表現するみたいです。うーん、確かに UML では、Use Case で Actor と機能の関連はモデル化するけど、Actor の組織的な構成、機能のモデルは明示的に支援していなかったので、ある意味、UML よりもビジネスモデリングと言う意味では強力かもしれない。
どちらかと言うと、ソフトウェアの世界ではなく、経営工学的な世界から出てきたモデルですね。これを使っている人もソフトウェアじゃない人が多いと思います。それをソフトウェアとして実現するには、何かワンクッションいるのかな。
たけをさん>他に私の把握してるものでは、先ほど挙げたgIBISに使われているIBIS, 他にQOC, DRL なんていうものが記法としてあるようです。
ご紹介ありがとうございます。何か良いリファレンスがあれば、また教えてください。
ハムレット＞軽く調べてみると IDEF0（Activitiy Modeling 手法）でその辺を表現しようって流れも有るようですね。
たけをさん>これは存じませんでした。
軽く調べただけなので、何なのですが。IDEF は元々アメリカ空軍で機材の調達プロセスの効率化を動機に開発された業務プロセスの表現手法のようです。 0,1,3 とあって IDEF0 は添付した図にもあるように、Activity Modeling のための表記手法で、ちょうど DFD（Data Flow Diagram）に 制約条件と機構（コンテキスト？）を追加したような図になっています。UML には該当するような図はないんですが、制約条件と機構で Design Rationale を表現しようとしているのかな。（元ネタは http://www.jeel.co.jp/idef_ov.htm です。）
そう言えば IDEF0 ではこれに追加して、組織モデルの表記手法も持っており、それと連動させて表現するみたいです。うーん、確かに UML では、Use Case で Actor と機能の関連はモデル化するけど、Actor の組織的な構成、機能のモデルは明示的に支援していなかったので、ある意味、UML よりもビジネスモデリングと言う意味では強力かもしれない。
どちらかと言うと、ソフトウェアの世界ではなく、経営工学的な世界から出てきたモデルですね。これを使っている人もソフトウェアじゃない人が多いと思います。それをソフトウェアとして実現するには、何かワンクッションいるのかな。
たけをさん>他に私の把握してるものでは、先ほど挙げたgIBISに使われているIBIS, 他にQOC, DRL なんていうものが記法としてあるようです。
ご紹介ありがとうございます。何か良いリファレンスがあれば、また教えてください。
たけをさん>でもニーズは非常に同意できるところがあるので、lightweightなもので、うまく設計手法に織り込めるようなものがあるといいんでしょうねぇ。
確かに道具立てとしては、利用者から見ると Lightweight な物が望ましいですよね。要は使い勝手ってところでしょうか。
知識工学の要素も含むんでしょうが、別の観点で考えてみます。以前、教育工学の先生と色々とお付き合いがあったのですが、教育工学って
＊教材コンテンツの有り方（教育対象と学習者の関心事からどのような構造を持つコンテンツを用意すれば良いか）
＊学習を容易にする UI の有り方
の２点に着目したシステムの研究・開発のような事をやっていました。
教材の代わりに設計ドキュメント（へのアノテーション）、学習モデルを設計理解モデルに置き換えて考えれば Design Relationale に対するいいアプローチになるのかなって事も思い出しながら、考えてみたりもします。
確かに道具立てとしては、利用者から見ると Lightweight な物が望ましいですよね。要は使い勝手ってところでしょうか。
知識工学の要素も含むんでしょうが、別の観点で考えてみます。以前、教育工学の先生と色々とお付き合いがあったのですが、教育工学って
＊教材コンテンツの有り方（教育対象と学習者の関心事からどのような構造を持つコンテンツを用意すれば良いか）
＊学習を容易にする UI の有り方
の２点に着目したシステムの研究・開発のような事をやっていました。
教材の代わりに設計ドキュメント（へのアノテーション）、学習モデルを設計理解モデルに置き換えて考えれば Design Relationale に対するいいアプローチになるのかなって事も思い出しながら、考えてみたりもします。
タイミングを外しちゃってる気がするんですが、遅ればせながら参加させていただいてよろしいでしょうか？
といっても、私は開発者がほとんど常に保守担当者であるような環境で仕事をしていたので、赤の他人にわかるように設計ドキュメントを書くという経験がほとんどありません。あるとしたら、会社を辞めたときくらいですか。。。(笑)
というわけで、もう一つの方向の話題についてなんですが、
> ２）最悪の事態を想定して、運用でカバーできるような仕掛けを作る。
ちょっとずれるかもしれませんが、以前日経サイエンスの記事でリカバリー指向コンピューティングというお話を読んだことを思い出しました。仮にダウンしたとしてもできるだけ早く回復できるようにシステムを構築しようというものです。確か、マイクロリブートとかいって、システムを細かい部分に分け、ダウンしたところだけを素早く再起動できるようにしようという筋書きだったような。
うろ覚えですいません。
といっても、私は開発者がほとんど常に保守担当者であるような環境で仕事をしていたので、赤の他人にわかるように設計ドキュメントを書くという経験がほとんどありません。あるとしたら、会社を辞めたときくらいですか。。。(笑)
というわけで、もう一つの方向の話題についてなんですが、
> ２）最悪の事態を想定して、運用でカバーできるような仕掛けを作る。
ちょっとずれるかもしれませんが、以前日経サイエンスの記事でリカバリー指向コンピューティングというお話を読んだことを思い出しました。仮にダウンしたとしてもできるだけ早く回復できるようにシステムを構築しようというものです。確か、マイクロリブートとかいって、システムを細かい部分に分け、ダウンしたところだけを素早く再起動できるようにしようという筋書きだったような。
うろ覚えですいません。
こんばんわ。
おとんさん>タイミングを外しちゃってる気がするんですが、遅ればせながら参加させていただいてよろしいでしょうか？
えー、そんなご丁寧に。こちらからお願いしたいぐらいです。どうぞいらっしゃいませ。 ((ﾉ(_ _ ﾉ)
おとんさん>以前日経サイエンスの記事でリカバリー指向コンピューティングというお話を読んだことを思い出しました。
確かにサーバーなんかでは色々と必要になるんでしょうね。ググッてみてもあまり出てこないですね。ネットワークストレージの関係で少しあるぐらいで。研究としても地味なのかな。確かにソフトウェアのみの研究と違って、ハードウェアも絡む研究だと、機器の試作も入ってきそうなので、実施できる所が限定されて来るのだろうか。
ただ、先にあげた ＩＢＭの Autonomic コンピューティングとも目的とか思想的には似ているのかもしれないですね。
おとんさん>タイミングを外しちゃってる気がするんですが、遅ればせながら参加させていただいてよろしいでしょうか？
えー、そんなご丁寧に。こちらからお願いしたいぐらいです。どうぞいらっしゃいませ。 ((ﾉ(_ _ ﾉ)
おとんさん>以前日経サイエンスの記事でリカバリー指向コンピューティングというお話を読んだことを思い出しました。
確かにサーバーなんかでは色々と必要になるんでしょうね。ググッてみてもあまり出てこないですね。ネットワークストレージの関係で少しあるぐらいで。研究としても地味なのかな。確かにソフトウェアのみの研究と違って、ハードウェアも絡む研究だと、機器の試作も入ってきそうなので、実施できる所が限定されて来るのだろうか。
ただ、先にあげた ＩＢＭの Autonomic コンピューティングとも目的とか思想的には似ているのかもしれないですね。
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
ソフトウェア工学 更新情報
-
最新のアンケート
-
まだ何もありません
-
