研修3日目。
前日作った新業務フローをベースに、
エンティティとアクティビティのマトリクスにて、CRUD図を作成した。
エンティティ・アクティビティの洗い出しは、前日に決めていたので、
それに基づいて記号を入れていったが、createがどこでもされていない
エンティティや、createされて以降どこからも参照されない
アクティビティがあったり、特定のエンティティに処理が集中したりと、
なかなか前途多難な図ができあがった。
createのみのエンティティは、不要と判断してざっくり削除した。
アクセス集中したエンティティは、おそらくプロセス分割を
検討すべきなのだろう。
引き続き、そのCRUD図を用いて、サブシステム分割の検討もやりました。
まず、サブシステムをどう分けるか。考えられるのは、
①業務別、②OUTPUT単位、③稼動サーバ別、④ユーザの部署単位別 くらいが、
意見として上げられました。
個人的には、①かと思っていて、グループディスカッションでも
①が採用されました。他グループでは、④を採用しているとこもありましたが。
①のメリットとして、処理の一連の流れごとに纏めることができるので、
わかりやすいのかと。とはいえ、④も、運用側・顧客側で、互いに
サブシステム単位で窓口を一本化できることが、メリットになりうるのかと。
サブシステム分割後に、情報の流れを、システムと顧客部署を混ぜて
描く作業をやりました。サブシステム間の流れは、他システムIFに、
サブシステムと顧客部署間の流れは、画面(or帳票)出力箇所だと、
直感的に認識しやすいことに、気づかされました。
この流れ図には、正常系しか載せませんでしたが、ユーザとの調整なら
正常系のみで良いと思うが、SE同士の認識あわせ資料とするんなら、
逆に異常系も盛り込んだほうが、良いかもしれないとの指摘をいただきました。
とはいえ、使い分けはむずかしいですね。
