奇妙なことですが、ソフトウェア開発の分野で直接生まれた方法は、外部から来た方法とはまったく似ていません。
たとえば、説明がシートA4に簡単に収まるが、CERNが使用するかなり単純なSCRUM。 または、アジャイル。これは、GitHubや他の多くのクールな作品が作成された非常に一般的かつ理想的な原則を含む10の段落で説明できます。 建設に使用できますか？ そして、航空機を作成するとき？
いいえ、待ってください。しかし、ビジネスプロセスの分解と形式化についてはどうでしょうか。それなしでは、同じ設計プロセスを自動化することは不可能です。 しかし、それがなければ、そのようなプロジェクトのために1000のテーブル、論理構造、インターフェースを作成することができなかった作業計画についてはどうでしょうか？
（実例として、一見すると非常に魅力的で信じられそうな、オーサーシップRuxxSilverの典型的な普遍的な方法論の顔）
地平線上では、マテリアルの生産を見続け、それを構成するエンティティの相互接続を再現しますが、これは非常に重要です。ランドスケープを表示してスケッチブックに描く方法です。 IDEF、UML、およびコンサルタントとビジネスアナリストの小隊が私たちを助けてくれます。 風景が消えると、まったく異なる原則が作用します。 大規模な生産自動化プロジェクトが失敗するのは、自動化オブジェクトをモデル化することがまったく不可能だったからではありません。 高炉の操業や部門の従業員の不在の事実を見逃すことは困難です。 または、これをモデルにどのように反映するか、およびこれが何を伴うかを理解していない。
ソフトウェアが頻繁にプロジェクトの詳細を騒ぎ立てて拒否したため、彼らは失敗し、予算から飛び出しました。 さて、50万個の部品の相互接続はシステムに適合しませんでしたが、すべてが適合するという前提に基づいて構築されました。 元のシステムの制限により、発行された領収書を突然返すロジックを書くのに10人時ではなく、10,000時間がかかりました。 データベースへのクエリで19を超える結合を行うと、レポートシステム全体が破壊され、サードパーティモジュールは3ギガバイトのメモリしか認識せず、4つが必要になります。
ソフトウェア製品に現実世界を反映して、私たちは本質的にキメラを作成し、そのコンポーネントは異なる法則に従って生き、異なる法則に支配され、予測不可能な瞬間にお互いを拒否し始めることができます。 大規模なユニバーサルデータベースの開発は、車両部品間の関係の記述の作成とはまったく異なります。 残念ながら、多くのマネージャーはこれを私たちが望むよりも頻繁に混乱させます。
特定の製品と仕事へのアプローチを持つ特定の組織はそれぞれ、独自の方法でキメラの問題を解決します。 共通のプロパティを1つ持つ非常に複雑なメソッドが作成されます-それらは、前駆会社のしきい値を超えると機能しなくなります。
正直に言って、RUPの使用に成功したのは誰ですか？ 私の棚にはRUPに関する本と、電子形式の本がいくつかあります。 残念ながら、誰がこれを行うかはわかりません。 インターネットもこの質問に答えるのにあまり役立ちませんでした。
IBMのしきい値を超えると、彼はボールのように吹き飛ばされ、それをはるかに非公式な方法と区別するすべてのものを失います。 現実の世界と密接に関連している形式化されたプロジェクトでは、開発の少なくとも一部を完全に形式化されたカスケードに変え、特定のソフトウェア製品、それらの長所と短所に結び付けられない方法にほとんど常に負け始めます。
汎用性は常に良いとは限りませんが、常に良いように聞こえます。
犬を訓練したい場合は、1つの方法で行動します。 車でどこかへ行きたいなら、別の場所へ。 そして、最初と2番目のケースでは誰かが何かをコントロールしているという理由だけで、これら2つの問題を解決するための一般的な原則を考えるべきではありません。
ソフトウェア製品を作成する場合、主にそれを構成する抽象的なエンティティ、外部インターフェイス、およびそれが存在するソフトウェアおよびハードウェア環境を扱います。
現実の世界をモデル化するとき、オブジェクト、測定可能なプロパティ、およびそれらの関係を扱います。
ソフトウェア製品は、現実世界の特定の部分のモデルが組み込まれることを示唆する場合があります。 次に、実世界を記述して、そのモデルをプログラムに入力しやすくします。
これが同一であると考えると、私たちは暖かくやわらかく混乱し始めます。
少なくとも、情報技術の本質に影響を与える対立のため。 コンピュータとそのプログラムは、コンピューティングシステム（特に統計処理）の子であり、コピー機です。
たとえば、石の分類と管理を扱う場合は、石のクラスまたは石を説明するデータベース内のテーブルを作成する必要があります。
最も安価な形式では、石は統一されます：石No. 1、石No. 2、石No. 3 ...現実の世界では同一の石はありません。 すべての石を説明するには、それらを完全に再現する必要があります。 重量でグループ化されたシステムに多くの石を導入することができ、その観点から、石の均一性が大幅に低下し、特定の石が実世界でどのグループに属しているかを判断しやすくなります。 一部のタスクでは、この石のグループがトラックに収まるかどうかに関する情報が役立つ場合があります。 問題は、どの程度の詳細が有用であるか、この利点がどれだけコストと組み合わされるかです。
オブジェクトの循環と非特定性が高いほど、そのオブジェクトに関する情報を処理しやすくなります。 そして、それを処理して変換するソフトウェアを作成するために必要な作業が少なくなります。
そして、普遍的な方法を本当に主張したいのであれば、集合論から始めて、それらの基本原理を探す必要がありそうです。 現在、このような試みは、非常に複雑な装置を形成しているため、リスク評価や非常に特殊なエキスパートシステムのプロジェクトでの顕微鏡的応用のみを見つけています。 実際には、それらは「気まぐれな」ブラックボックスの形で使用することができ、他のすべての意見の権威が疑わしい場合にその意見が考慮されます。
要約：さまざまな目標があり、それに応じていくつかの原則があります。優れたソフトウェアの作成方法、現実世界のモデルの作成方法、結果から経済的利益を引き出す方法です。 誰かがこれらのことを普遍的な方法と混ぜると主張する場合、これは経済目標のゾーンを指します。「普遍的」はクールで、「普遍的でない」よりも売れるからです。
普遍性は、さまざまな組織やプロジェクトへの適用性の観点から不可能です。 そのような移植性の程度が高いほど、この手法は曖昧な推奨事項のコンパクトなコードに似ています。
悪いニュース：自分で目標を決め、妥協点、最適点を探し、「良いコードが必要か？」のような陰湿な質問に答えなければなりません。 建設のように美しい滝のプロセスの可能性は、近い将来には不可能です。
市場の成長が低下し、個々のサブセクター内の競争が増加するにつれて、個人的な責任を持つ特定の人々の個人的な決定がますます重要な役割を果たすようになります。 ソフトウェア開発管理は絶滅することはありませんが、ほとんどの既存のITマネージャーは、そのアプローチとともに絶えず、専門的に成長します。 残りは、業界が彼らにとって簡単なキャリアとお金の面で彼らにとって有望ではなくなって、消えることを決定するでしょう。 これによって何かが失われることはまずありません。
そして、若いITプロジェクトマネージャーまたは開発チームリーダーが15〜30歳の本当に若い人であると思われる場合、若い建築家（建物を設計する）は30〜45歳の年齢範囲に入り、最初にアルバム「20若い建築家」を開きますあなたの考えは次のようになります：「そして、これらの古いオナラは誰ですか？！」。 5-7年の研究と10年の実践だけでは、フルシチョフでさえもうまく設計するには不十分だからです。
次の記事では、1つ下のレベルに進み、顧客として継承した概念と要件の強さを試します。