システム工学に関する推論と「リチャードハミング：第28章システム工学」に関する解説

リチャード・ハミングはこの記事にコメントしようとしました。第28章 「システム工学」の問題を理解し、「近代」を考慮し、それに関連するか、部分的に複製することでシステム工学をEA \ BPMで。

オリジナルからの抜粋は、イタリック体の他のソースからの引用に示されています。 さらに、システムエンジニアリングに関する推論。

システムエンジニアリングまたはシステムエンジニアリング（SE）も、BPM（ビジネスプロセス管理）およびEA（エンタープライズアーキテクチャ）と同様、よく知られた分野です。 SEが終了し、EAとBPMが開始する場所を見つけるのは困難です。 これら3つの分野はすべて、特にマーケティング面で「進化」しています。

「大きく複雑な」デザインはすべて、SEに基づいている必要があります。 エンタープライズ設計（およびこれは複雑なシステムです）、エンタープライズのアーキテクチャの説明はSEではありませんか？ SE規格は、多くの場合、エンタープライズとアーキテクチャの両方を使用しています。 エンタープライズシステムエンジニアリング（ESE）の個別のラインも割り当てます

エンタープライズのアーキテクチャにシステムエンジニアリングを追加する方法 （物語）があります

単純なシステムでは、原則としてBPMは使用されません。つまり、「全体BPM」もSEについてのものであり、SE規格は常に「モデリング」と「プロセス」について言及しています。
したがって、SEを加算せずにEAまたはBPMを想像することは困難です。合計すると、3種類のEA-BPM-SEが得られます。

SEは「大規模で複雑な」すべての設計であるため、定義により、「SE＆PMBOK」、「SE＆ITSM」を含む「Best Practice」およびxxBOKから知られるほぼすべてと交差しますが、示された「troika」に限定します「そして、EAとBPMを批判する私のサイクルで述べられたことを考慮に入れて：

エンタープライズアーキテクチャとAlchemy Enterprise
ビジネスプロセス：すべてがどのように起動され、混乱するか（BPM）

重要な結論：EAとBPMを錬金術と見なし、SEがそれらのアプローチに反論せず、むしろ「補足」、そしてしばしば「複製と繰り返し」に反論するなら、SEは工学の専門分野であるという主張を疑うことができます。

最新のSEの問題はEAとBPMの問題と同じです。承認の詳細な公開例はありません。 ほとんどすべてのプロジェクトは、NDA、パーティクルボード、および「軍事秘密」によって閉鎖されており、プロジェクトの段階的な例はありません。 しかし、SEアソシエーションでの多くの収益、多くのマーケティング、コース、販売など。

SEについて少し

システムエンジニアリングは、顧客のニーズと期待と制約のセットを効果的なソリューションに変換し、ライフサイクル全体でこれらのソリューションをサポートするために必要な技術的および管理的取り組みの完全なセットを定義する学際的なアプローチです（ISO 24765）。
sewiki.ru

IBMの書籍「ダミーのシステムエンジニアリング」から

システムエンジニアリングは、特定の一連の経済的および技術的要件を満たす大規模な統合システムを作成するための学際的なアプローチです。
航空宇宙および防衛産業では、システムエンジニアリングが長い間使用されており、経験的に得られた知識の多くは他の分野にも応用されています。

Wikiシステムエンジニアリング
-かなり控えめ。

ただし、 Wikiシステムエンジニアリングのように

ソビエトのシステム工学/システム工学の学校は、当時の西洋の学校よりも劣っていなかったという事実にもかかわらず。

何らかの理由で、チャンピオンシップはアメリカからアメリカに与えられています（議論の余地のある質問）：
伝説によれば、システムエンジニアリングは、2つの非常に複雑なエンジニアリングプロジェクトを横断する必要があるときに、米国の軍事産業で作業を行う方法として最初に登場しました。 この問題の解決に対処できる「一般設計者」の目標はなく、そのようなスーパープロジェクトの複雑さに対処する方法を考案する必要がありました。
システム工学的思考

ソビエトの同様のプロジェクトは、同じSEアプローチを使用していなかったと思います。

SEは、システムおよび複雑なシステムの設計、実装、および保守に関するものです。 システムエンジニアリングによって問題を解決するプロセスには、問題の設定、基本的な技術的解決策の発見、システムのモデリング、最適化、アーキテクチャ、製造と発売、試運転、および結果の製品（「システム」タイプの製品）の有効性の分析が含まれます。

さらに、これは非常に重要です-このアプローチは、まず第一に、コンサルタントや開発者ではなく、開発消費者（顧客）の利益を守ります。 いずれにせよ、これはもともと意図されていました。

システムエンジニアリング標準

SEのタスクの視覚的な反映は、（条件付きで）絵と見なすことができます（ちなみに、PMBOKタスクのように）： Tarzankaプロジェクト

1.開始

最初の3つのパラグラフ、「第28章システムエンジニアリング」から「大聖堂の建設を見た男」では、「木の向こうの森を見ないでください」という簡単な真実を述べています。 これは、人々が詳細に集中し、「全体」を見ない典型的な状況です。 これについて多くのことが書かれています。 私が持っているもの：
3.5森林、木、葉
2つのタスク（カテゴリ）に分けることができます。「フォレスト」（「大きなセル」のプロセス、鳥瞰図）を記述するタスクと、十分に詳細な「プロセス-木」

彼らは自分の仕事で狭い見方を示し、システムのより一般的な目標とそれを関連付けることはめったにありません。

このような狭い視野は、官僚の主な特徴です。

おそらく「官僚」ではなく、高度に専門化された専門家です。 実際、「個別のサイト」を最適化しようとしても、「システム全体」のパフォーマンスが常に向上するとは限りません。

システムエンジニアリングは、主な目標を常に念頭に置いて、各ローカルアクションが実行される理由と全体的な結果にどのように影響するかを理解する試みです。

すなわち 「森」と「木」の両方を見る能力、「森」の発展の法則（生命）と「木」の完全に異なる法則（生命）を理解し、各「木」には独自の法則があります。

実際、これは大規模な検討から小規模な検討へ、またはその逆への移行のメカニズムです。

当然、私はすぐに、科学者自身が直接作業するときに新しいマシンから最大の価値を引き出すことができることに気付きました。

ITスペシャリスト（BPMスペシャリスト、EAアーキテクト、その他の錬金術師）やプログラマーを使用せずにビジネスプロセスを記述および最適化するためにビジネスユーザー自身を「直接」引き付ける必要があるため、私はこのアイデアを当面予測します。

これについては、「 ビジネスプロセス：すべての起動と混乱の仕組み」の記事で説明されています。 第3章 一般的なBPM分類とBPMSの哲学
長年、欲求（夢番号2）は消えませんでした-BPMの専門家が「正方形と円を描く」ことに関与することなく、参加者によってプロセスを直接シミュレートする簡単な方法を見つけること、およびこの方法で構築されたプロセスの実装。 したがって、BPMS形式に対する強い渇望（希望）

それぞれの場合の義務は、（1）直接拠出、（2）長期拠出、（3）非常に長期の拠出でした。 また、ポイント（2）および（3）の下で、研究部門での私の役割の1つは、既存の問題を解決することではなく、問題を解決するための方法を開発し、可能性の範囲を広げ、他の人に見つけられることを教えることであることに気づきました私の努力の結果をさらに適用し、継続し、改善します。

これをEAサイクル「エンタープライズアーキテクチャとエンタープライズアルケミー」で伝えようとしています。 EAおよびBPMへの既存のアプローチの変革は以下を目的とする必要があることを示します。

既存の問題に対するそれほど解決策ではありません...

つまり さらに、EAの一時的な説明を作成していません。NDAとチップボードによって閉じられています。 この方向の純粋なマネタリゼーション。 そして、問題が本当に「解決」されていることは非常に議論の余地があります。 多くの場合、失敗（失敗）プロジェクトBPM \ EA \ SEは成功として表示されますが、真実を見つけることは不可能です。

問題を解決する方法を開発し、可能性の範囲を拡大し、他の人にどのように教えるかによって、どれだけ...

これは、「問題を解決する方法」それ自体ではなく、方法論と神秘的なフレームワークではなく、具体的な例のデモ、理論的な「ベストプラクティス」のテスト、実用的な「ベストプラクティス」の公開を通じて、オープンディスカッションを通じてのみ可能です。 残念ながら、これは現代のEAおよびBPMおよびSEには当てはまりません。

...私が見つけたものは、彼らが私の努力の結果をさらに適用し、継続し、改善できるようにするためです。

EA、BPM、SEの多くの実務家は個人的な利益のみに関心がありますが、全体としての方向性の開発、または「錬金術」から「化学」への移行に関心がある人はほとんどいません。 EA、BPM、およびSEビジネスは、コンサルティング、コーチング、ツールなどで繁栄していますが、実践と「レーニン理論」に関しては、「良い理論以上に実用的なものはありません。」 実用性へのオープンアクセスの証拠はありません;一般的に、EAとBPMとSEの実践からは何もありません。

すべてが「実用的」、つまり すべての例は、営利目的または国家秘密です。 方法論とそれらで完了したプロジェクトは成功していると誰が言ったのですか？ 何に基づいていますか？ そして何の利益のために？

しかし、後になって、研究部門のニーズだけでなく、研究所のすべてのニーズにも注意を払う必要があることに気付きました。

それからAT＆T、AT＆Tの外の国、科学および工学コミュニティ、そして最終的には全世界でした。 したがって、私は自分自身、私の部門、部門、会社、親会社、国、科学者とエンジニアの世界、そして地球のすべての住民に対して義務を負っていました。

私たちの仲間の市民にとって、そのような義務はもっとあるでしょう。 特に、SEを実践するか、他のSEの方法を教える人のために。 特に、国内のSEの開発を担当している人に。

SE理論と私たちの国に関して：GOSTの崩壊後、現代の同様の組織（Rosstandart、Roskachestvoなどを含む類似の国家機関）は、収益化（認証、技術規制などを通じて）、規制などに焦点を当てています。しかし、SEを含む科学および工学の実践の開発ではありません。

これはすべての問題、つまり標準化、統一、類型化、ベストプラクティスの自由な交換です。 国内のSE-34.xxxシリーズのGOSTと、15.xxxおよび2.xxxシリーズの多くです。

それらを果たす義務は過去に残っていましたが、当時は主に軍事システムの生産において強力な可能性を提供していました（GOST RV 15.xxxおよび2.xxx。）。
行われている最大のことは、外部GOSTの翻訳です。

これらの分野における独自の（国内の）方法論的発展はゼロです。
なぜ今日必要なのですか？ けれども、わが国がこれらの産業の先駆者になれば、少なくとも複雑なシステムの設計における標準化と統一へのアプローチにおいては。

そうです-これは必要ありません。なぜなら 私たちと：

a）西洋の発展に満ちている-ほとんどが錬金術に関連しているが、収益化にはこれは必須ではない。
b）多くの「石油とガス」があり、すべての人（少なくとも多くの人）に十分な「パンとサーカス」を提供します。 「パンとサーカス」がたくさんあると、萎縮を起こす誘因になります。

EAとBPMとSEも、情報をコーディングするためのアプローチとして表され、完全に形式化できると確信しています。 そして、これらの分野はいつの日か本当の科学と工学の分野になるでしょう。

システム工学で正しい言葉を言うのは非常に簡単であり、このトピックで質問されたときに多くの人々がそれらを話すことを学んだが、テニス、ゴルフ、水泳などの多くのスポーツのように、一般的に必要なことをすることは難しい。 したがって、システムエンジニアは、彼らが言うことではなく、最終的に実行および生成されるため、判断されるべきです。 良いゲームについて話す人はたくさんいますが、実際には彼らはそれをすることができません。

「システムエンジニアは彼らの言うことではなく、その結果によって判断されるべきだ」という考えをさらに発展させたいと思います。
そして、国内航空、自動プロムはどこにありますか、国内「SEプロム」（開発34.xxx）はどこにありますか、少なくとも工学、システム工学からの何かはどこにありますか？ 「西洋の錬金術」を翻訳し、西洋の「キット」を再販し、そこからシステムをスカルプト（統合）することしかできません。これはITとあらゆる場所にあります。スーパージェットと現代のラダの80％は輸入部品と技術です。

もちろん、この基準では、エンジニアだけでなく、リーダーとすべての市民（これはすべて暗黙の了解です）を判断する必要がありますが、まず、「大規模システム」と国内の「システムエンジニアリング」を担当するエンジニアがここにいます。 私は政治については望んでいませんでしたが、それはハミングからの引用に続きます：「彼らが最終的に何をして生産するかを判断するために」。 そして、実際に生産されるものは何ですか？ 主にその西側の対応者によって生産されました。

システムエンジニアリングの最初のルール

コンポーネントを最適化すると、ほとんどの場合、システムのパフォーマンスが損なわれます。

差動アナライザーの接地の問題は、どういうわけか私には完全には明らかではありません。 むしろ技術的な欠陥です。

私は別の例を挙げますが、あまり示唆的ではありませんが、別の方向にあります。古いおもちゃであるDiggerを思い出してください。 プレイ済み-プレイ済み、すべて順調でした。

その後、新しいコンピューターが登場し、...それらのアーキテクチャは互換性があったものの、それらでプレイすることが不可能になりました。 速度が大幅に向上したため、「粗末なDigger」はすぐに「食い尽くされました」。新しいシステムは非常に迅速に機能しました。 コンピューターの計算能力を非常に「最適」に最適化しています。

時間が経つにつれて、そのようなゲームにはプログラムが登場しました-「モデレーター」、つまり、プレイするには、古い車のパフォーマンスと比較するためにパフォーマンスに「バラストをかける」必要がありました。 結論：「オプティマイザー」タブレットに「アンチオプティマイザー」タブレットを適用する必要がある場合があります。

別の最適化の例：一部の職人は、生産車にエンジンを強制しました。 その後、半軸（トランスミッション）、特に前輪駆動車の「手rena弾」を「吐いた」。 もちろん、最適化は、システム全体（チェーン）の「弱いリンク」を考慮して、包括的に行う必要があります。

この場合、アクティビティは条件付きで「最適化」に起因する可能性がありますが、これは単純に、最初のケースでは計算、2番目のトルクでの容量の増加です。

これらは、「バターでポリッジを台無しにしない」という原則が機能しない場合の例です。複雑なシステムでは、常に機能するとは限りません。

試験前に詰め込むのは時間の無駄です。

私は批判をよく理解していません。 一般に、学習プロセスの主な目標はトレーニングです。 人間の記憶（RAMの構築）、思考プロセス（CPUと脳DSPの計算能力）のトレーニングと開発。 オントロジーの例、概念的なデバイス。 これにより、実際のタスクを簡単に類推できます。 タスクは異なります-ソリューションへのアプローチは同じです（システム全体）。

実際に適用される調査対象はごくわずか（ほとんど何もありません）です。これは明らかにトレーニングの標準です。 しかし、これは「学習が難しく、戦いが簡単」という原則に基づいています。 瞬間的に、騎兵隊は時代遅れになり、戦車に置き換わるかもしれませんが、戦術の要素（突破防衛、側面迂回）は同じままです。

ちなみに、パラドックスは国内の大学でのトレーニングの問題でよく見られます。敗者は素晴らしいキャリアを達成し（トップへ）、優秀な学生はエンジニア（普通の従業員）で「ズボンを拭きます」。

システムエンジニアリングは従うのが難しいプロセスなので、詳細に迷子になりやすいです！

はい、それは事実ですが、これまでのところ、SE、EA、BPMの分野のみが「錬金術」の開発レベルにあります。 それが本当の科学になり、詳細で実証済みの（実証済みの）テスト済みの旅行があると、初心者でも「簡単にフォローできます」。

「ABCブック」によると、ABCブックレットSE、EA、BPMのいずれか（またはこれらすべてが一方向に崩壊する）がわからないため、ACSまたはエンタープライズを段階的に構築することが可能になります。 錬金術との比較は、SE、SEよりもEAおよびBPMをより明確に示していますが、主に標準化により、それらと比較してより高度です。

SEには既に「マーケティングの足」がありますが。 SEの重要な問題（繰り返します）は、EAおよびBPMに関して、SEメソッド（プロジェクト）の実装の公開された例がないことです。

その結果、全体として見た場合、数学の教育に大きなギャップが生じました。 （1）数学的帰納法の重要な方法、（2）代数の二次方程式との簡単な言及の後、実際には触れません。複雑な固有値と固有関数が現れる運命の日まで、そして貧しい学生同時に2つの新しい複雑な概念に精通し、もちろんこれは彼を混乱させます。（3）不確かな係数の有用な方法が簡単に述べられ、（4）それらはほとんど完全に無視されます。 lstva不可能、（5）は、離散数学、（6）現実世界での適用の重要な概念に訓練例を考えて学生をもたらすために行われている何の努力を無視されていません。

ソ連にも同様の問題があったと確信しています。 一方では、ソビエトの教育は、高度に専門化された「西側の」教育と比較して、より「統合されたアプローチ」（「広い視野」）で有名でした。 しかし、一方で、これは「現実の世界」からの距離をさらに大きくしました。

私はこれを現代ロシアの教育について言います。現在、この国では「現実世界に適用可能な概念」に重点が置かれています。 国の「現実世界」だけが産業時代ではないため、「会計とマーケティング」の概念は流行しています。

「経済学者および会計士-未処理の犬のような」国、学校およびマーケティング大学など 科学と工学は傍観者であることが判明しましたが、それが私たちの衛星がハエのように落ちている理由であり、誰も国内の飛行機、車、コンピューター、電話について議論することさえしません。

真剣に議論しない、すなわち マーケティング、州のプロパガンダ（巨大なメカニズム）、「正しいフィーダー」への投資、個人やプロジェクトの広報、一般的には民間のレベルでのみ。

工学の専門分野では、科学の分野ではなく、率直な錬金術がしばしば教えられます。 錬金術の指導について：
「時間が経つにつれて、そのような教科書や本の表紙には、「Alchemy Handbook」という碑文が突然現れます。一部の人々は、そのような碑文のまだ曖昧な輪郭をすでに認識できています。」 habrahabr.ru/post/345948

それが理由です：

...多くの人々は何を言うべきか知っていますが、現実の世界で行動する時が来たときに実際にそれを実行できる人は多くありません。 あなたのほとんどはできません！

将来のエンジニアがマーケティングと錬金術を教えられたため、それはできません。 体系的なアプローチであるシステム分析は、コンサルタントのカラフルな小冊子にある「概念と戦略」の必須属性ですが、実際には単なる「管理策略」です。

「彼らには生産ラインがありました...」という言葉は、産業用コンベアなどに関するものです。 （G.フォード）、明らかに、SEと直接的な関係はありません。 どのデザインも実際には同じデザインコンベヤーです。

さらに、適切に編成されていれば、「ACSおよび企業」の生産のためのこのような組立ラインの労働者の能力と「創造性」の要件が大幅に削減され、品質が向上し設計時間が最小限に抑えられます。

設計の柔軟性により、システムのインストール後に必然的に発生する変更にうまく対処できるだけでなく、設計の後の段階とシステムのフィールドトライアルの両方で必然的に発生する小さな変更の形で自分の作業に貢献できます。 クワジェリン諸島のナイキプロジェクトのフィールドテストに参加する前に、テスト中にどれだけの変更が行われるかを理解していませんでした。

大規模システムの受け入れテスト行為における大きな間違いは、「エラーなし」を記録することです。 「テスト段階でエラーは検出されなかった」ことを示すのは正しいことです。エラーは存在している必要がありますが、まだ発見されておらず、排除されていないためです。

システムのプロトタイプに文字E1および後続の文字On（GOST 2.103-2013）が存在しても、エラーがないことを保証しません。 設計およびドキュメントの変更を迅速に導入すること（設計の柔軟性）は、カスケード設計の標準です（何らかの理由で、「柔軟性のある」アジャイルにのみ起因します）。これは、構築中および生産中です。

第二のルール

システムエンジニアリングの設計の一部は、他の部品のパフォーマンスを低下させずに、それらを正常に通過させるための変更の準備です。

この論文は、ITIL-「リリース管理」などの特別な場合に、「変更管理」、「要件管理」の個別の現代領域に進化しました。

前に書いたように、設計アプローチの半減期は15年です。これから学習するアイデアの半分は、15年後には役に立たなくなります。

疑わしい論文。 自分自身への投影：軍事システム（ACS）と建設GOSTおよびSNIPの開発へのアプローチの研究を与えられました。20年前に同じものに関する現代文学よりも、ラッパー「EA \ BPM」および「マーケティングチップ、ビジネス目標など

時間が経つにつれてますます優れた技術文献がありますが、主な問題は、ジャンクをマーケティングすることによって形成される「干し草の山」で失われ、インターネット中に流通することです。 理論と推測の実践によって確認されていないマーケティングと錬金術の「雪だるま式」の成長軸は、現代の現実です。

代わりに、実際の例、プロジェクト、承認、およびこれらの方法論とフレームワークを使用して実装されたシステムの詳細な分析の結果の同じアーカイブ（リポジトリ）を見たいと思います。

一般に、全国のGOST 34.xxxを読んでいない人が、SEによるISO / IECの内容をどのように理解できるかはほとんど想像できません。それらは「一般に」曖昧に書かれています。
定性理論が開発された場合、それは「不滅」であり、需要があります。
ただし、180度のコース変更ではできませんが、開発する必要があります。

ちなみに、ACS（24.xxx、34.xxx）と建設（21.xxx）およびその他（ESKD-ESPD）の状態標準仕様、ARIS方法論のステージ、その他（私は覚えていません）の設計段階を比較しましたすでに）。 そして、それはすべて一つのことになりました：

1）事前プロジェクト（事前プロジェクト、コンセプトなど）
2）概略設計、技術設計、作業ドラフト
3）テスト、受け入れ、実装

異なる方法論には異なる用語がありますが、本質は、示されたステージ内を含めて、驚くほど同じです（クラシックカスケード）。 さらに、規模に関係なく、ラジオ局、タンク、建物、自動制御システム、企業を構築しています。

この「クラシックカスケード」は、実際には複雑なシステムの設計に対する「システムアプローチ」の基礎です。

興味深いことに、同じSEの原則が示されているこれらの非常に「異なる方法論」は、SE、およびEAとBPMに直接関係する可能性があります。 たとえば、TOGAFの設計段階については、 エンタープライズアーキテクチャとエンタープライズアルケミーに関するコメントで説明しています。 パート2.簡単なフレームワークとシンプルなエンタープライズ

では、なぜそんな方法論の動物園なのでしょうか？
私たちは「深刻な製品」について話している、私は（カスケードの代替として）アジャイルの使用などを信じている 戦車や航空機、または原子炉または「デッドハンド」タイプのシステムの開発における「基礎として」-それは誰にも起こりません。

第三のルール

仕様をより正確に満たすほど、過負荷時のパフォーマンスが低下します。

これは「最適化」の要素です。 最適化からの脱却-「信頼性の向上」、安全マージン、生産性などに向けて -「支払う」、「最適化しない」を支払う必要があります。 生産性のマージンを含む「強度」のマージンを持ちたい場合、最適化は優先順位を付けない方が良いです。

ケースが薄くなると、製品は安価で軽量になりますが、耐衝撃性が低下し（同じ素材を使用）、保護されます。 したがって、家と橋は安全な余裕を持って建設されるべきです。
すべての最適化は妥協管理です。 マッチでお金を節約し、要件に正確に従って構築できますが、主な品質は失われます。

...小さなタスクは大きなタスクよりも比較的重要だと思いました。

これは、「森の木々の向こうに森を見ないで」という論文の続きです。 一般に、この論文はSEの主要なポイントの1つであり、しばしば繰り返されます。IBMの書籍「System Engineering for Dummies」を参照してください。

「すべてのツリー」を最適化することにより、フォレスト全体を台無しにすることができます。 一部のツリーが非常に大きくなり（「個人のローカル最適化」）、それらを破壊する他のすべてのツリーを影で覆う場合のみ。 「システム全体のグローバル最適化の達成」は失敗します。

私と同じように、ウェスターマンは、クライアントがいくつかの症状に気づいている間、彼らの本当の原因を理解していないかもしれないと信じています。 そして、それは愚かで、症状だけを治そうとします。 したがって、システムエンジニアはクライアントの声に耳を傾ける必要がありますが、クライアントから現象をより深く理解しようとする必要があります。 したがって、システムエンジニアの仕事は、問題が何であり、症状から実際の原因に移行する方法をより深い意味で判断することです。

これにより、たとえばITSMに「ケース管理」、「インシデント管理」、「問題管理」などのさまざまなブランチができました。 これらは、異なる結果（インシデント）を1つの原因（問題）にリンクする方法です。

複雑なシステム内の要素の因果関係と振る舞いは明らかではなく、要素の関係の視覚的表現（画像）を通じて問題を理解できるようになると、これらの関係を識別するための領域全体が識別されます（「構成管理」など）。

Westermanは、明らかに、システムエンジニアリングの技術は、新旧両方の顔を含むチームで最もよく研​​究されると考えています。 同時に、経験豊富な同僚を徐々にプロセスから削除し、新しい人をチームに紹介する必要があると彼は言います。 「孤独な狼」の個人的な経験を伝える方法がわかりません。 特定の状況で何をしたか、どのように行動したかについてのみ話すことができます。

そして、私は同じことについて話している：SE、EA、BPMで特定のプロジェクトを公開し、「何とどのように」ガイドがどこから来たのか（標準、フレームワーク）、これらの同じ標準とフレームワークがどのように適用され、どのような問題が発生し、どのようになったかを示すだけで十分解決しました。 「伝えるだけ」で、具体的で詳細な実例または架空の例を示してください。

しかし、もう一度明確にしましょう。 システムエンジニアリングは、特定のソリューションの特定の問題に対する古典的な単純化の強固な基盤の上に構築する必要があります。

「敵を1つずつ倒す必要があります」。複雑なタスクは部分的に解決（つまり、分解、単純化）する必要があります。 -これらはすべてSEの戒めであり、「森と木」に関するものと同じです。
鍵となるSEドキュメントは何ですか？ GOSTやISO / IEC 15288
やシステムエンジニアリング知識体系（SEBoK） などの方法論ではなく、
特定のシステム（プロジェクトアーティファクト）の実用的な文書です。

これは、その動作原理や詳細な仕様を示すシステム動作図ではなく、プロジェクト「クランベリー」（システムの各要素の一連のプロジェクト文書）と地理（システムコンポーネントの地域分布）でさえあります。

これは、製品をコンポーネント部分に分割するスキームです（GOST 2.711-82）。これは、システムを要素に詳細化したものです。製品を個別のサブ製品-コンポーネント、さらに製品（「複合システム」タイプの製品、購入した製品など）に分割します。

チーフデザイナーのオフィスに行くと、彼は6x3の壁のほぼ全体を1つの「分割パターン」だけで、かなり小さな要素（数百）で構成しています。これは、ハミングの声明です。

システムエンジニアリングは、主な目標を常に念頭に置いて、各ローカルアクションが実行される理由と全体的な結果にどのように影響するかを理解する試みです。 ただし、特定の大きな画像はありません。

これは「1つの具体的な全体像」であり、10進数や「開発済み」または「購入済み」製品などの説明も含まれています。

「私たちの」GOST分割スキームの類似物は、「彼らの」ISO / IEC 15288の「D.1.3システム構造」であり、1982年に「私たち」だけが標準としてフレーム化され、より詳細な表記があります。一般に、SEで「現代の」西欧標準を読むとき、GOST 2.xxx、34.xxx、およびGOST RV 15.xxxからの類推を思い出します。

EAの観点からすると、そのような「1つの特定の全体像」とは、特定の企業向けの完成したZahmanタブレットです（Zahmanフレームワークは以前の記事で示しています）。どうやら、大きなシステムをサブシステムに分解するとき、それぞれ-独自の（別個の）Zahmanプレートの下でコンパイルする必要があります。

すでにこれについて言及しましたが、もう一度言いましょう。より深い理解を提供しない解決策は悪い解決策ですが、これが現在の制限時間内にできることのすべてである可能性があります。システムエンジニアリングの目標は、問題の本質をより深く長期的に理解することであると同時に、クライアントは常に現在の症状に対する即座の解決策を求めています。繰り返しますが、メタシステムエンジニアリングにつながる競合！

理想的には、ユーザー（クライアント）は常にERP、ACSなどを期待します。モード：「仕事に来て、大きな赤いボタンを押すと、それ以上何もする必要はありません。システム自体が動作します。主なことは、シフトの終わりに大きな赤いボタンを押すことを忘れないことです。

どうやら-これは空想またはしきい値であり、その後SkyNetが続きます。

システムとその問題の詳細な理解の例として、ナイキの誘導ミサイルプロジェクトを検討したいと思います。

システムエンジニアリング「そこ」（米国）とシステムエンジニアリング「ここ」（ソ連）の夜明けは冷戦中に来たと確信しました。わが国の「温暖化」の後、それは一般に国内の「ベストプラクティス」として消滅し消滅し、そこで一種のマーケティングツール（一般にこのカテゴリーISO 9000のリーダー）に変わりました。どうやら、生存への脅威として人を動員するものは何もない。

システムエンジニアリングは、エキサイティングな職業であり、実践するのは困難です。

ACSおよびエンタープライズ、組織プロセスの設計-SEの実践を常に意味します。私の意見では、SEについて読むべきことがたくさんありますが、これは科学ではありませんが、「マーケティング」フィルターを通してユーティリティをフィルターできます。

したがって、EAおよびBPMおよびSEに関する本（特に記事）を読むには、「注意マーケティング」とささやく必要があります。例外は、本（西部のものを含む）およびソビエト時代のロシア国家標準仕様です。マーケティングから除外することもできますが、国内の科学と産業が「ひざまずき」、すべてのイデオロギー、方法論、および「完全性」が西洋のものであるかどうかは明らかではありません。

プロセス制御システムに適用されるSEに関する実用的な書籍：「プロセス制御システムの設計」、Nesterov。

「フルプログラム」システムエンジニアリングの実践は、防衛産業でのみ見ることができますが、使用されるテクノロジーのレベルはまったく異なるため、最近のスローガン「輸入代替」（基本的な工業化を読む）はすでに明らかに埋もれています。したがって、ポスト工業化について話すことは単純にばかげています。私たちはまだ（またはすでに）「産業化前」にいます（ロールバック）。

SEとは

ハミングの理解におけるシステムエンジニアリング-「システムエンジニアリング2018」および今日のシステムエンジニアリングと同じですか？おそらくそうです。

SEはシステム設計アプローチです。どのシステムですか？どれでも、難しい。より正確には地上。ソーラーシステムは、明らかに他の方法論に従って設計されなければなりません。理想的には、SEは技術システムだけでなく、経済的および社会的なシステム（共産主義を含む、なぜですか？「明るい未来」になるために、「1917」フレームワークに基づくロードマップ2）の構築方法を説明する必要があります。

SEに従って単純なシステムを設計することもできますが、「最適ではありません」。

SEの普遍性は、「体系的なアプローチ」の原則の「採用」によるものです。これは、「複雑なシステム」として開発された（近代化された）製品の統合ビューです。

原則として、「部品」と「プログラム」は「システム」カテゴリに含まれません。このカテゴリでは、たとえば「飛行機」や「ビッグプログラム」（ERP）など、難しいものが選ばれています。ACSや「エンタープライズ」などのオブジェクトは実際の「システム」です。

PMBOKuと同じように-その上に実装するプロジェクトが何であれ、SEにとってはそれほど重要ではありません-その上にどのような「システム」製品を構築して実装するかは重要ではありません。
「飛行機」、「ACS」、「エンタープライズ」などのシステムは、SEの異なるブランチに従って設計する必要があります（原則は一般的ですが、詳細があります）。

ACSの設計は一般的であるため、GOST 34.xxxのフレームワーク内で、さまざまなクラスのACSと単純に「自動化されたシステム」を設計するアプローチの組み合わせが行われました。

一般に、SE、EA、BPMのトピックに関する多くの最新の記事と「発見」を読むとき、州の標準仕様ではなく、長い間読まれていると感じることがよくあります。 「企業情報システムとそのユーザーに関する佐賀」などの20年前の記事を思い出しますが、その始まりを見る
ことができます。
それから、トピック「企業情報システム」に関するすべての本は、EA、BPM、SEを組み合わせたものでした。今日、KIS、ACS、ITKSの概念は「古くなっています」が、問題はまったく同じままでした。

おわりに

システムエンジニアリング\システムエンジニアリング、EA、BPM-一般に、「同じもの」でなければ、関連する概念。ポジショニングとマーケティングの主な違い。ただし、同様の概念：ERP、CRM、ドキュメント管理システムなどたとえば、「クライアントアプリケーションを処理する」同一のモジュールが、これらのソフトウェアシステムの主要な要素になる場合があります。

システムエンジニアリング、EA、BPM-ハミングコードのように、いつか本当の科学と工学になるはずです。これは非常に形式化された装置である必要があり、要件（ウィッシュリスト）、設計、品質管理、およびクラス「システム」の製品の実行の精度の形式化を可能にします。

どんな種類の「システム」でも構いません。ACS、軍隊によるACS、産業用制御システムまたは州の情報システム、「電子政府」、または世帯、企業（IP、SME、「法人」）を含む「エンタープライズ」（EA）全体、状態。

この場合、初心者の設計者であれば、「ハミングコード」の説明と同様に、SE、EA、BPMを簡単に実践できます。

SEと自動化全般の主な動機

すべては、メカニズムとこのメカニズム用の制御システム（SU）があるという事実に帰着します。メカニズムは、車またはハードウェアとソフトウェアの複合体などです。メカニズムは、人またはロボット（自動、悪魔）または一緒に制御されます。

ロボットは常に指示に従って行動し、人は指示に従って、または「独自の裁量で」行動します。したがって、ビジネスルール、実行ロジック、アルゴリズムなど。 -指示書、プログラム、またはアーティストの「頭蓋骨」に保存されています。主なものは、それら（ルール）が常にそこにあるということです。

SEメソッドは、システムの設計プロセス（つまり、テンプレート、フレームワークに従って設計）とシステムのメンテナンスプロセス（テンプレート、規則に従って）の両方で、後者を最小化することを目的としています。

「人による決定」が必要になった場合、その設計決定はチーフデザイナーであり、重要な取引はディレクターによって締結され、これは規制（権限の制限など）、記録、文書化されます。

ロジックの相関関係：ロジックプログラム（ソフトウェアアルゴリズム）に縫い付けられた「ペーパーインストラクション」からのロジックと、エグゼキューターの「スカルボックス」に縫い付けられたロジック-EA記述の詳細レベルを含む「自動化レベル」、「形式化レベル」を決定します「。 SEは、「創造性」（「自由」の制御）と複雑なシステムの設計と保守のための明確に規制されたプロセスの構築を最小限に抑えることを目指しています。設計と実装に関する明確な規制。

単純なシステムでこれがすべてそれほど重要でない場合、複雑で、特に重要な場合、それは単に必要な条件です。 「複雑さ」の管理には、システムがどれほど複雑であっても、プロセスを実装するための明確でシンプルな概念フレームワークとシンプルな手順が必要です。

今日、SEはEA領域（エンタープライズ設計またはそのACS）、またはプロセス設計（BPM）のいずれにおいても本格的なエンジニアリングを許可していません。確かに、これはSEの仕事ではないが、これは言い訳に過ぎないと言うことができます。

それでも、SE標準はEAやBPMよりも理解しやすく、より便利ですが、私が理解しているように、SE標準は毎年それらの下で実装されるプロジェクトの削減があります。いずれにせよ、（主観的な感情や出版物によると）20年前には10年前よりも多くの人がいましたが、今日では10年前よりも少なくなっています。

SEの未来

民間システム、特に予算資金のための国家システムの設計の絶対的な近さの現代的なアプローチに驚いています。この「壁が崩れ」、デザインが「盲目的」ではなく、例とプロトタイプの膨大なベースが与えられると、SE、EA、BPM、およびその他のデザイン領域に対するアプローチがまったく異なります。

数千のアナログを含むシステムの技術仕様を開発するには-何がポイントですか？ SEは、他の誰も持っていないユニークなシステムにのみ必要です。それらは初めて開発されています。そのようなシステムは、総質量の0.1％以下です。すべてのシステムとすべての企業はユニークであり、TKとRFPを通じて「ゼロから」設計する必要があるといえば、「マーケティングの秘”」です。

時間の経過とともに（明らかに共産主義下で）、システムを構築するための基礎は、コンサルタントが販売するだけの「ベスト」としてコンサルタントが発行したソリューションではなく、本当に最高のソリューションを借りることになります。参照（参照）モデル、標準プロジェクト（プロジェクトの標準形式）、プロトタイプ、ソリューションの統合-これらは将来の設計の重要な要素です。これは、オープンな設計と設計ソリューションの無料交換でのみ可能です。

Studopedia（学生がエッセイ、学期末レポート、テスト、論文、レポートを書くのを支援する情報リソース）との類推により、デザイナー向けの同様のProjectopediaが表示されるはずです。

彼は1日で「急いで」記事を準備したので、「リチャードハミング：第28章システムエンジニアリング」の翻訳の直後に読まれたため、どこかで不正確にアイデアを表現し、おそらくどこかで「興奮しました」特に、「柔らかく」動詞を拾い、「真実の子宮を切り刻んだ」）、不正確さと誤植を作りました。

あなた、bipiem