モジュール内強度、モジュール間結合度

１つのモジュールは１つの機能で組み立てられていなければならず、かつ出入り口は１つでなければならないという趣旨のプログラム設計理論です。現在多くの開発を経験してますが、なかなかこの点が一般では理解されていません。むしろ汎用機全盛期にはこの考え方がきちんと採用されていたように感じています。
是非皆さん勉強してくださいね。

※只今家族が病気のため更新が滞ってます。メルマガも出せていません。お詫びいたします。

メソッドの話を前にしましたが

日本人の国民性というのでしょうか、例えば「習うより慣れろ」とか「人の技を盗め」といった
メンタリティーで仕事を覚えていくというのは以前からそう変わっていないように思います。
これは職人を育てていくにはある意味合理的なのですが、大量に人を育てるときは、それも
「極める」ではなく「一定の水準」に育てるにはどうしてもメソッドが必要になってきます。
以前、プロジェクトＸという番組があり、東京オリンピックの食事のプロジェクトで大量の料理人を
育成する必要に迫られたとき、帝国ホテルの料理長がすべてのレシピを公開したことが
番組になってました。当時の料理界ではおよそ考えられないことなんですよね。
ところが今でも多くの業界でかなりマニュアルは整備されたとはいえ、メンタリティーが
追いついてないと思います。われわれのソフト業界でもおそらく同じに感じてます。

帰納と演繹

まず、Wikiか何かで「帰納」と「演繹」という言葉を調べて見てください。
おそらは検索エンジンにWikiに限らず、引っかかると思います。
まず、これが我々のコンピュータソフト開発の基本理論です。
一般事象すなわち業務を抽象化＝モデルに置き換えること、
このモデルが実際の業務遂行に当たり、適用できるかを検証し、
その上で実際のプログラムとして実現できるわけです。
失敗しているシステムの特徴としてプログラム中に多くの例外条件や
エラー条件がハードコーディングされています。
これはメンテナンスの障害となるとともに入力エラーチェックとの
不整合に起因するデータ不整合や異常終了の原因にもなりえます。
ERPであろうがなかろうが、モデル化は不可欠な考え方です。

SEになるメソッド

これはコンサルでもPGでもそうですけれど、存在していないと思います。
小難しい理論やコンピュータ言語の教育はありますけれど。
どの工程に従事していても帰納と演繹の繰り返しなんですよね。
でも、これを行えるようになるメソッドを教育している会社とかは
正直知らないです。
一般的な事象からモデルが作れるようにならないと、
なかなか難しいですよ。

更新が遅れて申し訳ありません

家族が病気でその看病のため多忙で更新が遅れてしまいました。
今週末当たりからぼちぼちはじめて行きたいと思います。
しばし、お待ちをm(_ _)m

SAP CRMとABAPのメルマガも週末には出しますので･･･。

SAP CRM情報発信！

４月２２日(日)にメルマガを発行します。SAP CRMのアドオン開発のメルマガです。
よろしかったら是非登録してくださいね。よろしくお願いします。
ご登録はSAP Chipsまたはhttp://www.melma.com/backnumber_167838/

データの項目と流れを

まだ文章として固まっていないけれど、こんな感じでしょうか。

データ→ヘッダーと明細がある。
　　　　　マスターとトランザクション（取引）データがある。
　　　　　明細に対してサマリーデータがある。

一度もERPの仕事をしたことがない人はもし機会があったらチャレンジすると面白いと思います。
上記がどう実現されているのか。それはゼロから開発するときにきっと役に立ちます。ERPだけ
やっている人はDB設計のイロハから一度勉強する必要があるかもしれません。

うまくまとまんないですが。