植山さん、こんにちは、上手です。
勉強させていただきます。
よろしくお願いいたします。
> はじめまして。植山です。
>
> 「業務システム」のモデルを作ってみました。
> 下記URLにてユースケース図とクラス図を公開してます。
> http://homepage3.nifty.com/ueyan/model/
ぱっと見ただけで、相当のベテランだなと思いました。
切り分けがきれいに階層的になっています。
実務も知っているし、論理的な思考を必要とする（上流の）仕事をされているの
ではないかと感じました。
>
> 週末に仕上げて、提出予定です。
>
> 下記メモをモデルを見るときの参考にしてください。
> １）業務＝業務マニュアルに則って事務作業を行うこと
> ２）事務作業では各種サービスを利用可能
> ３）運用は、システムリソースを扱える運用作業を含む業務
> ４）ハードやソフトを複数の業務システムで共有することを
> リソースの占有率で表現する。
> ５）調達、リース、保守・・・は、サービスの利用で表現？？
>
>
> 実は、お題との整合性をまだとってないです。
> 締め切りまでまだ時間がありますのでぼちぼち修正します。
>
> みなさんの意見をお聞かせください。
> よろしくお願いします。
気のついたことだけ、コメントします。
１ 課題では、業務システム＞（業務カテゴリー＞）サブシステム＞機能
となっています。業務カテゴリ＞業務＞事務作業、の階層と食い違っています。
２ 事務作業という名称が、う〜ん、って感じです。
事務作業の継承がシステム運用というのは名前のミスマッチという感じがします。
３ 植山さんのクラス図では事務作業＞サービス＞システムサービス／人的サー
ビス、の分割はするどいと思います。
問題なのは、業務には手作業を含むのが当然と思いますが、業務システムが原則
として、どこまで手作業を含むかを課題が定義していないような気がすることで
す。
・課題の求める範囲でモデルをつくるか
・一般に考えられることまで含んでモデルを描くか
悩み処ですね。
４ 調達では、課題が「新たに開発する部分がシステムの本体といえる」といっ
ていますが、これはおかしいです。
Web系の開発では、オープンソースをカスタマイズする開発が主流ですから、
「新たに開発する部分が開発の本体といえる」とはいえますが、これはシステム
の本体ではありません。
＃言葉尻の話ですが・・
これもまた３項と同じく、課題の定義通りにモデリングするかどうかですね。
（では）
> 以上