80/20はスケジューリングにも影響します

私たち全員が80/20の法則について聞いたことがあります。これは、成功（効果）の80％は、アクション（原因）の20％のみから生じるというものです。 さて、この普遍的な真実はソフトウェア開発にも影響を及ぼします。この記事では、このステートメントの基本を少し説明します。

BPM

ビジネスプロセス管理は、英語の頭字語で、（とりわけ）ビジネス（または他の多くの場所）で実行する必要のあるプロセスを視覚的に理解できるようにする管理分野です。 その主な特質の中には、複雑なプロセスを分析して「単純」にすることができるという事実があります。

BPMダイアグラムを開発できるオープンソースツールはたくさんありますが、この記事で使用したのはBonitaSoftです。 プロセス管理についてもう少し学びたい場合は、インターネット上に多くのチュートリアルとその主題に関する本があります。 それでは、中心的なトピックに戻りましょう。

ソフトウェアプロジェクト

今日、プロジェクト開発にはアジャイル、従来型、ハイブリッドなど、さまざまな手法が存在します。それらすべてに共通しているのは「準備」です。これはどういう意味でしょうか？つまり、このソフトウェアプロジェクトの成功の80%は、プロセス全体の最初の20%、つまり準備にかかっているということです。

プロジェクトの準備

これは論理的な論点ですが、現実にはめったに適用されません（実際には非論理的な他の多くの論理的な事柄と同様です）。準備について語る際には、問題の理解、解決策の理解、そして何よりも解決策が採用するプロセスの理解が不可欠です。プロ意識に欠けるソフトウェアプロジェクトで最もよく見られる問題の一つは、この点に関するドキュメントの欠如です。これは通常、販売意欲が開発プロセスを覆い隠してしまう民間企業で発生します。

これらの記事を読む人の多くはテクノロジー関連の仕事をしているか、またはテクノロジーに関係しているため、彼らの仕事人生において、十分な準備基準を満たしていない企業やサプライヤーに遭遇した場合、プロジェクトがうまくいかない可能性はほぼ80％あることを述べておく価値がある。

抽象化が鍵です

これは私がGNU/Linuxを使っていた経験から学んだことで、ソフトウェア開発プロセスにおいて何度もその重要性が証明されてきました。問題を抽象化し、よりシンプルなものに変換する能力は、洗練された、そして何よりも耐久性のあるコードを生み出すために不可欠です。そして、おそらくこれが、大規模なプロフェッショナルプロジェクトと、制御不能に肥大化するプロジェクトとの主な違いの一つでしょう。前者はプロセスを熟考し、理解し、構造化するのに対し、後者は理解することなくただ実行し続けるだけです。

Stager

これは、Gentooインストーラーが開発するプロジェクトの名前です。ご想像のとおり、これは多数のアーキテクチャーをサポートしているため、非常に複雑なプロセスです。 考慮すべきもうXNUMXつの要素は、カーネルレベル、initシステムなどでサポートされる構成の数です。 それは私の論文プロジェクトでもあるので、これをすべてお話しします。これは、勉強を終える前に終えなければなりません。 もちろん、こんなに短い時間（来年XNUMX月まで）ですべての選択肢を考えたプログラムを作ることはできませんが、少なくとも機能的なシステムを非常に基本的な方法でインストールできるプログラムを作ることはできます。

インストールプロセスを理解する

BPMツールのおかげで、Gentooをコンピューターに正常にインストールするために必要な手順を理解できるプロセス図を生成できます。

いくつかのプロセスとサブプロセスが含まれているにもかかわらず、それは明らかにかなり要約されており、18の線形ステップがあることがわかります。 線形構造のアプリケーションは実装が簡単であると同時に、必要に応じてXNUMXつ以上のスレッドで並列処理を生成できるため、これは重要です。

もう一つの重要な要素は、プロセス群をタイプ別に抽象化できることです。例えば、カーネルサブプロセスを定義することで、その中にカーネルのインストールを正常に完了させるプロセスに直接関連する特定のタスクが存在することを把握できます。

このようにして、各「複雑な」ステップは、必要な詳細を失うことなく、全体的な方法で「単純な」ステップになります。これにより、プロセスを正常に完了するために必要な仕様のレベルを下げることなく、アセンブリの視認性が向上します。そして、ハンドブック全体を一度に読むよりも画像を見る方が簡単であることは否定できません 

時間を節約する

もうXNUMXつの明らかな利点は、直接接続されたプログラミング言語がないため、言語の実装に時間を浪費することなく論理分析を実行できることです。 これは、より効率的なソリューションがあるために機能が破棄されることを確認するためだけに機能の実装に費やすことができる時間と比較した場合の利点です。 擬似コードの解決策と同じように（多くの「開発者」によっても無視されているが、そうすべきではないもの）。

プロジェクトの指揮が簡単に

これらの概念を考慮すると、(あらゆる種類の) プロジェクト管理がより簡単になります。なぜなら、本当に必要な部分に重点的に取り組み、この部分が正しく行われていれば、残りの部分は自重するからです。これがあなたの好奇心を助け、BPM やアルゴリズムなどを研究する動機になれば幸いです。もしかしたら、私の論文を手助けする励みになるかもしれません。 ここまで来ていただき、ありがとうございます。またすぐにお会いしましょう。ご挨拶