アナリストとして定義を常に提供しなければならないので、これらのルールを思い出すのは良かったです。
定義をそんなに真剣に考えているのはなぜですか？ 私は定期的に実際には使用できない定義を満たしているからです。 そして、改善する傾向は見られません。 まず、前回の記事で用語システムを分析した方法と類似して、用語プロセスを分析します。
多くのプロセス定義を見てきましたが、それぞれが互いに矛盾しています。 それらの1つを次に示します。
プロセスは、特定の結果を達成することを目的とした一連のアクションです。
矛盾の理由は、「プロセス」という用語だけでも多くの異なる概念を意味し（かつて私は30に数えて停止した）、1つだけの定義を与えようとするためです。 それらがすべて別々にリストされている場合、1つの単語で示されるさまざまな概念の30の定義があります。
単語が文脈から読みやすい少数の意味しか持っていない場合は良いことです。 たとえば、「ブレード」という用語の意味は、コンテキストから簡単に推測されます。 この用語の意味はシュガーの本を飾っています。
さらに悪いことに、たとえば、前の記事「 システムとデザインの概念」で検討した「コンストラクション」という用語で起こるように、コンテキストからどのような概念を話しているのか理解できない場合はさらに悪い。 情報システムの設計における彼らの位置 。 その問題は、現在の意味が明確ではないことです。1つまたは複数のオブジェクトは、両方とも同じ名前（構造）で示されるためです。 たとえば、小隊が定着していると言えば、この文脈では、オブジェクトと見なす小隊システムについて話していることは明らかです。 小隊が20人の戦闘機で構成されていると言えば、小隊について話していることになります。 さらに、用語「小隊」の最初の意味は、同じ単語「小隊」の2番目の意味とは関係ありません。 ただし、コンテキストを明確にしないと、議論されていることを理解することは不可能です：セットについて、またはオブジェクトについて？ 私たちの知り合いの言語学者が言ったように、このトピックはよく知られており、これは偶然ではありませんでした。 不要な用語で言語を過負荷にしないために、それらのいくつかは異なる概念を意味する場合があります。 ただし、ステートメントを形式化する際には、ここで明示的に区別する必要があるため、翻訳が困難になります。
さらに悪いことに、2つの概念があり、定義が1つである場合、用語システムで起こります。 システムエンジニアは、システムという用語の定義の1つから取り去られており、彼らがどのようにそれらを区別するかはわかりません。 そして、多くの概念があり、定義がプロセスという用語のようなものである場合、それは本当に悪いことです。 これは、機能、機能構造、機能のクラス、機能のタイプ、操作、操作のシーケンス、一般的な操作のシーケンス、操作のシーケンスのクラス、操作のクラスなどです。 その結果、プロセスアプローチに関与するほとんどすべての人が関数をスクリプトと区別できず、IDEF0表記を使用してモデル化すること、IDEF0表記のモデルがBPMN表記のモデルとどのように異なるか、ガントチャートのBPMN表記のモデルとは言えません。 したがって、この用語を聞くたびに、私は非常に強調されます。翻訳するために、対話者が話していることをコンテキストから理解するために、多くの可能な概念を同時に念頭に置かなければならないからです。 対話者は非常に多くの場合、用語プロセスをさまざまな意味で、時には1つの文で使用します。 そのような対談者を理解することは不可能であり、会話を止めることができます。 関数を表すプロセスという用語が、関数を表す関数という用語と対立する場合、別の間違いがあります。 そして、彼らは文字通り次のように言います：あなたが見る、機能は悪いです、そしてプロセス（機能の意味で）は良いです。 実際、管理へのプロセスアプローチの「発明」による操作は、このバランスをとる行為に基づいています。 構成という用語を定義した後、これに必要なものはすべて揃ったので、側面から見た様子を別の記事で説明します。
この記事では、「プロセス」という用語の定義に関して、会話の現在のトピック、定義の提出のための構成とルールを反映する部分についてのみ説明します。
特定の結果を達成することを目的としたプロセスを一連のアクションと呼ぶことにしたことを思い出させてください。 全体、構成など。 セットの指定です。 つまり、この定義では、プロセスはオブジェクトのセット、つまりアクションとして定義されます。 「アクション」という用語自体は単純ではありませんが、ここではそれを別としておきます。 とりあえず、次の論文を見てみましょう。誰かによる多くの行動は、結果を達成することを目的としています。 多くの人がそのような財産を所有できないことは明らかです。 セットには、セット内の要素の数、このセットに含まれるアクションの平均期間などのプロパティを設定できます。 （これは、列車という用語の定義で見たものとまったく同じです。機関車によって駆動される車のセットです。このセットが移動できないことは明らかです。このセットの要素は移動できます。 、オブジェクトが動いていないことを意味します）。 プロセスの定義では、一連のアクションから合成されたオブジェクトのみを結果に導くことができます。 したがって、結果に対するオブジェクトの方向に関しては、オブジェクトとしてのプロセスを意味していました。 オブジェクトとしてのプロセスは定義されていませんが、それへのリンクがあります。 システムの定義に関する問題を知っていますか？ システム、設計、プロセスという用語は、同時に多数のオブジェクトとオブジェクトの両方を意味します。 設計の定義でこれらの概念が離婚した場合、システムの定義で、そして今、私たちが見るように、プロセス-それらは1つのボトルにマージされます。 しかし、これらの定義だけを非難しないでください。 辞書のすべての定義はこれによって罪を犯します。 用語の定義は1つだけですが、別の定義は示していません。 たとえば、飛行機が乗り物であると言うとき、飛行機が多数の{尾、胴体、翼、着陸装置、モーター}であるとは言いません。 電車はたくさんの車だと言うとき、電車は乗り物だとは言いません。 私たちの知り合いの哲学者は、この問題が辞書編集で知られていることを確認しました。 彼女が言語学者に知られているなら、なぜ私たちは彼女について何も知らないのですか？ そして、私たちの無知は、モデルの構築にどのように影響しますか？
飛行機をセットとして合成すると、飛行機がオブジェクトとして生成されます。 列車をワゴンのセットとして合成すると、列車がオブジェクトとして作成されます。 アクションのシーケンスの合成は何を生成しますか？ オブジェクトとしてのプロセスとは何ですか？ 私自身にとって、これはアクションだと判断しました。 つまり、合成の関数は関数を生成するため、合成のアクションはアクションを生成します。 設計との類推により、プロセスは2つの異なる概念を定義します。
- プロセスは一連の連続したアクションであり、その合成は特定の結果を達成するために誰かが指示したアクションを形成します。
- プロセスは、特定の結果を達成するために誰かが指示するアクションであり、その設計は一連のアクションとして表すことができます。
任意のアクションをアクションに分割できるため、2番目の定義を簡素化できます。 それは判明します：
プロセスは、特定の結果を達成するために誰かが指示するアクションです。
用語システムの定義と同じ問題がありました。 わかったように、すべてのオブジェクトはシステム（o）であり、すべてのアクションはプロセス（o）であることがわかりました。 そのため、システムをオブジェクトではなく、アクションをプロセスと呼びます。 オブジェクトとその構造があると思います。 次に、航空機とその設計、列車とその設計に異なる定義を明示的に与えることができます。
最初のタスクを処理したら、次のタスクに進みます。 「特定の結果を達成するために誰かから指示された」とはどういう意味かを判断する必要がありますか？ つまり、主観的な視点が明確に定義に組み込まれています。 このアクションが結果を達成することを目的としているかどうかを誰かが教えてください。 どの定義でも、サブジェクトへの参照があります。 たとえば、水泳施設は水泳の対象です。 しかし、施設で泳ぐかどうかは誰が決めるのでしょうか？ ある種の主題。 このオブジェクトで泳ぐことができることに全員が同意する限り、スイミング施設に帰することができます。 しかし、これができないと言う被験者が現れるとすぐに、問題が発生します。この物体を水泳手段と呼ぶことができるのかどうか。 水泳用の乗り物で、ボートが船舶として認識されない場合でも同意できる場合は、指で数えることができますが、すべてのアクションはそれほど単純ではありません。 プロジェクトのある関係者からのアクションは有用であると考えられるが、別の関係者の観点からはそうではないということをよく聞くことができます。 アクションが役に立たない場合、プロセスと呼ぶことはできません。 1つのIPでのアクションは、1つのプロセスであり、1つのプロセスではないことがあります。 それには何も問題はありませんが、顧客がアクションが無意味で有害であることを知っているが、それを自動化するように私たちに頼む状況を想像してください。 たぶん彼はばかですか？ 知りません しかし、私たちは彼が自動化するように私たちに求めるものを何と呼びますか？ このプロセスは使用できなくなりました。 どこからも指示されていないアクションの名前は何ですか？
シュガーの本を思い出します。 彼は、新しい概念を定義するために、次のことを行う必要があると書いています。
- オブジェクトのスーパークラスに名前を付けます。 たとえば、椅子は家具だと言います。 家具は、椅子のクラスよりも幅広いオブジェクトです。
- 特定のクラスのオブジェクトと、より一般的なクラスのオブジェクトの特徴的な特徴（微分特性）を示します。 たとえば、椅子は4本の脚と背中を持つオブジェクトです。
- これらのオブジェクトによって解決（実行）されるタスク、実行される機能などのクラスを説明してください。椅子は座るように設計されています。 これらのタスクは、前述の差別的な兆候がハイライトされた理由を説明する必要があります：4本の脚-安定性のため（そしてなぜ3本ではないのですか？）
- 実行されるタスク、実行される機能に差別的な兆候を課す制限を説明します。 たとえば、椅子に物を保管することはできません。
適切な定義の例は、物理学で与えられる重要な点の定義です。 マテリアルポイントは、解決する問題の枠組み内のサイズを無視できるマテリアルオブジェクトです。
- スーパークラスはマテリアルオブジェクトです。
- 微分特性：対象の観点から見ると、他のボディとは異なり、マテリアルボディのサイズはゼロです。
- 解決すべき問題は、物体の軌道の計算です。 微分特性の理由は、計算の単純化です。
- 物理学の優れた教科書では、物質体をポイントとして表現することができる場合とできない場合の問題に多くの時間が費やされているため、制限を挙げません。
さらに、同じ主題をさまざまな方法で分類できるため、概念の完全な定義には、そのような各スーパークラスの最も詳細な説明と、微分特性を含める必要があります。 たとえば、水上飛行機は、航空機のサブクラスおよび浮遊機器のサブクラスとして解釈できます。 水上飛行機の定義では、これらのスーパークラスの両方を示し、飛行機やボートと区別する水上飛行機の特性の違いを説明する必要があります。
プロセスの定義（o）に戻ります。 プロセスは、結果を達成するために誰かが指示したアクションであることを思い出させてください。
- プロセススーパークラス-アクションクラス
- 微分符号-結果の達成に焦点を当てます。
- 微分符号を導入する目的は私には不明です。 この症状が解決するのに役立つタスクの範囲も明確ではありません。
- 制限：2人の利害関係者がアクションの有用性に同意しない場合、それをプロセスと呼ぶことはできません。
この定義で私を混乱させるものは何ですか？ ゲシェフトがアクションに課せられた制限から明らかでないこと：結果に焦点を合わせますか？ このかなり厳しい制限に自分自身を制限すると、どのクラスの問題をより簡単に解決できますか？ 答え：いいえ！ つまり、制限はありますが、gesheftはありません。 無意味で有害な制限。 ここでこの論文に、私はあなたをずっと失望させました。 問題以外の何も与えない定義があります。 それらは無意味で逆効果です。 問題の解決に役立たない場合、制限を導入しても意味がありません。
システムの出現について。 誰もがこの制限からのキャッシュフローが何であるか知っていますか？ システムが緊急と認識された場合、どのクラスのタスクをより簡単に解決できますか？
構造内のオブジェクトの数を複数に制限することから、どのような種類のgesheftがありますか？ なぜ要素の数がゼロの構成、または要素が1つの構成を考慮することができないのですか？