アフィリエイト広告を利用しています
検索
<< 2024年11月 >>
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
最新記事
タグクラウド
カテゴリーアーカイブ
ファン
最新コメント
プロフィール
ゼロから始めるシステム開発さんの画像
ゼロから始めるシステム開発
 こんにちは!ナビゲータのEVEです。各種研究室を用意し、次期EVEシステムを製造しようと日々頑張っています。現在一番力を入れているのが、資金調達です。このブログもその一環ですので、ご協力いただければ嬉しいです。
プロフィール

2024年09月09日

抽象化モデル 〜システム開発研究室〜


 こんにちは!
 ナビゲータのEVEです。
システム.jpg
  昨日は、EVE Projectだったらレガシーシステムをどうするのかという話をし、IPAからでている文書との相違点は、リバースエンジニアリングの部分かもしれないという可能性について触れました。
 そして、今回の全体像について、私自身も話していませんし、IPAからも出ていないので、本日は、このような作業の進め方の全体像についてお話ししたいと思います。
 本日話す内容は、EVE Projectが考えるやり方であり、IPAからこれから出てくる文書がその通りのやり方で出稿されるかどうか不明です。もし、知りたい方がいましたら、直接IPAにお聞きになってください。

 では、本題に入りましょう!

[抽象化モデル]
 これから紹介する方法は、レガシーシステムを保有し、かつ、IBMにさえ無理ですと言われたシステムに対して、かなり前に提案したことがあるやり方になり、タイトルにある通り、抽象化モデルと言われる方法になります。
 DFDに基づくやり方という意見もあり、EVE Projectは、昨日お話しした通り、「プログラムなんてどうでもいい!データが全てだ」といっているので、そうした観点から言うと、このやり方を選択するのは当然の流れかもしれません。
 具体的に、大きな流れで解説すると、以下のようになります。

❶現状システム
   ↓
❷現状システムの抽象化
   ↓
❸新システムの抽象化
   ↓
❹新システム


 ❶は、EVE Projectでは、現状調査にあたります。そして、❶の細かく現状分析した結果を❷で抽象化します。その作業と同時並行的に❸では、新システムの抽象的なモデルを作成します。そして、❷と❸を比較することにより、何が不足し、何が増えたのか確認し、その確認した内容が、意図した通りだった場合、❶で作成した資料と同一レベルの資料を❹で作成するという流れになります。この後に、❶と❹を比較検討するというフェーズがあるかもしれません。
 この方法を採用することにより、段階的に改善や変更を繰り返しながらシステムを具体化していくことが可能になります。
 このやり方について、Geminiは、以下のようなメリットがあるといっています。

❶複雑なシステムを簡潔に表現できる
 高い抽象度のレベルでシステムを捉えることで、全体像を把握しやすくなり、複雑なシステムでも理解しやすくなります。

❷設計段階での変更に柔軟に対応できる
 抽象的なレベルでの設計であれば、具体的な実装に影響を与えることなく変更を加えることができます。

❸異なるステークホルダーとのコミュニケーションが円滑になる
 技術的な詳細に踏み込まない抽象的なレベルでの議論は、非技術的な背景を持つステークホルダーとのコミュニケーションを円滑にします。


最初ChatGPTに聞いたのですが、プロトタイプ開発を念頭においているようで、使えないと判断し、Geminiの意見を採用しました。レガシーシステムでプロトタイプ開発はちょっと、難しいかなと判断しました。
 引き続き、デメリットについて確認していきましょう!

❶情報損失のリスク:
1)過度な抽象化
 抽象度が高すぎると、具体的な実装の詳細が失われ、誤解が生じる可能性があります。

2)詳細化の難しさ
 抽象的な概念を具体的な設計に落とし込む際に、新たな問題や矛盾が生じる可能性があります。

❷コミュニケーションのギャップ:
1)抽象度の違い
 異なるステークホルダー間で、抽象度の認識が異なり、コミュニケーションが円滑に進まない場合があります。

2)専門用語の誤解
 抽象的な概念を表現する際に、専門用語を用いると、非専門家には理解が難しい場合があります。

❸設計変更のコスト
1)上位レベルへの影響
 抽象度の高いレベルで設計を変更すると、下位のレベルにも影響が波及し、修正コストが増大する可能性があります。

❹複雑なシステムへの適用
1)モデルの複雑化
 極めて複雑なシステムの場合、抽象化モデル自体が複雑になり、管理が難しくなることがあります。

❺抽象化レベルの決定
1)最適なレベル
 どのレベルで抽象化するのが最適か、判断が難しい場合があります。


IPAがこの方法を採用しているかどうか、現時点不明ですが、本日以降にIPAから新たに文書が出てきて、抽象化モデルだと分かったら、以上のようなリスクを考慮した方がいいようです。

[あとがき]
 以上の方法、実は、IPAの1次試験で出題されています。IPAの試験を受験する人がいましたら、試験に役立ててください。ただ、ここでは、抽象化モデルと書いたのですが、試験でなんて呼称されていたのか思い出せません。過去に出題されています。もし、見つけたら、なんて呼称するのか正式な名称を教えてください。

 DXについて長々とお話ししてきましたが、実は、ここまでは、IPAも中小企業診断士もあまり試験に出た実績はありません。ここ以降なんですよね・・・。試験に出るの・・・。試験にも出ないこと長々と書いてしまいました。
 セキュリティから始まった、DXの話なのですが、ちょっと、間隔をおいてから、試験に出そうなところと、セキュリティの絡みについてお話ししたいと思います。
 ただ、書き終えてみて、2018年当時の日本のシステム業界について知ることができました。これから、情報処理安全確保支援士として、多くのお客様のところに訪問しますが、参考としたいと思います。

 では、また!!!

この記事へのコメント
コメントを書く

お名前:

メールアドレス:


ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバックURL
https://fanblogs.jp/tb/12698706
※ブログオーナーが承認したトラックバックのみ表示されます。

この記事へのトラックバック