システム詳細設計における、変更要因に基づく分解の仕方について

Question

実現したいこと

変更要因に強い分解の仕方を理解する

発生している問題・分からないこと

今、大学の科目の一部で、変更に強い内部設計書を作成しています。GRASP、SOLID 原則に基づいて作成する必要があります。そこで、ユースケースから変化要因を考える時、どのように考えれば、納得感のある変更要因を特定する事が出来るでしょうか？AIに聞きましたが、少し解答に違和感がありましたので質問させて頂いております。経験ある方、教えて頂けたら幸いです。宜しくお願い致します。

該当のソースコード

特になし

試したこと・調べたこと

• teratailやGoogle等で検索した
• ソースコードを自分なりに変更した
• 知人に聞いた
• その他

上記の詳細・結果

AIに聞くと、将来起こりうる要因を特定する事とありますが、一度も実務経験が無いため、まず起こりうる要因が何なのかすら想像出来ません。AIは、いくつか変更要因を割り出してくれますが、それがTrueなのか、Falseなのか判断出来ません。なので体系的に理解したい為、アドバイスを頂きたいです。

補足

特になし

Comments

[otn]

質問ポイントは、「実際に業務本番稼働しているシステムで、プログラムを修正する要件としてどんなものがあるか、とあるシステムでいいので実例を知りたい」ということかと思ったのですが、これだと、素人でも「小売店システムの消費税軽減税率制度誕生」「Teratailシステムへの意見交換機能追加」など思いつくはず。
そういうのじゃなくて、もっと抽象的なことを言ってますか？

Answer 1

システムが対象とするドメインによって変更要因というのは色々あると思います。

一例ですが、

• 組み込み系の場合
  • センサやメモリなどの部品が製造中止になるので新しいものに置き換える必要が生じた。
  • 機能向上のために扱えるI/Fの種類を増やす(今まではイーサネットだけだったがUSB typeCも使えるようにするなど)
• WEB系開発の場合
  • 今使っているWEBサービスが運用停止になるので新しいサービスに移行しなければならなくなった。
  • オンプレミスで運用していたサービスをクラウドに移行することになった。
  • システムがサポートするファイル拡張子の種類が増えた。

などです。
基本的には、システムが生きている間に、時間とともにそのシステムが構成する部品の数や種類が変わる可能性がどれだけあるか、また変わった時のインパクトがどれくらい大きいかということを分析することになるのかと思います。

ちなみに、システムが生きているというのは、製品リリース後も派生開発が続いている、またはサポートを継続しているという状態を指しています。