私たち全員が80/20の法則について聞いたことがあります。これは、成功（効果）の80％は、アクション（原因）の20％のみから生じるというものです。 さて、この普遍的な真実はソフトウェア開発にも影響を及ぼします。この記事では、このステートメントの基本を少し説明します。
BPM
ビジネスプロセス管理は、英語の頭字語で、（とりわけ）ビジネス（または他の多くの場所）で実行する必要のあるプロセスを視覚的に理解できるようにする管理分野です。 その主な特質の中には、複雑なプロセスを分析して「単純」にすることができるという事実があります。
BPMダイアグラムを開発できるオープンソースツールはたくさんありますが、この記事で使用したのはBonitaSoftです。 プロセス管理についてもう少し学びたい場合は、インターネット上に多くのチュートリアルとその主題に関する本があります。 それでは、中心的なトピックに戻りましょう。
ソフトウェアプロジェクト
今日、プロジェクトを開発するための多くの方法論があり、アジャイル、伝統的、混合などがあります。 それらすべてに共通するXNUMXつのポイントは 準備。 これはどういう意味ですか？ このソフトウェアプロジェクトでの成功の80％は、プロセス全体の最初の20％に基づいています。 準備。
プロジェクトの準備
これは論理的なものであり、実際にはほとんど適用されません（実際には非論理的な他の多くの論理的なものと同様）。 準備について話すとき、私たちは問題を理解し、解決策を理解し、そして何よりも、 プロセス 解決策が適用されること。 専門外のソフトウェアプロジェクトで最も見られないことのXNUMXつは、この主題に関するドキュメントの欠如です。 これは通常、販売したいという欲求が作成プロセスを超えているため、民間企業に見られます。
これらの記事を読んだ人の多くは仕事をしている、またはテクノロジーに関連しているので、仕事のある時点で、適切な準備が整っていない会社/サプライヤーを見つけた場合、ほぼ80％確実です😛プロジェクト それはうまくいきません.
抽象化が鍵です
これは私がGNU / Linuxを使用していた時間から学んだことであり、ソフトウェア作成プロセスの鍵となることが何度も証明されています。 の容量 概要 それらをより「単純な」ものに変えるための問題は、エレガントなコードを生成できるようにするために不可欠であり、とりわけ 丈夫。 そしておそらくこれは、大規模な専門プロジェクトと制御不能に成長するプロジェクトの主な違いのXNUMXつです。 前者は考え、理解し、構造化する プロセス 秒の間 彼らは保つ それを理解する必要なしに働く.
Stager
これは、Gentooインストーラーが開発するプロジェクトの名前です。ご想像のとおり、これは多数のアーキテクチャーをサポートしているため、非常に複雑なプロセスです。 考慮すべきもうXNUMXつの要素は、カーネルレベル、initシステムなどでサポートされる構成の数です。 それは私の論文プロジェクトでもあるので、これをすべてお話しします。これは、勉強を終える前に終えなければなりません。 もちろん、こんなに短い時間（来年XNUMX月まで）ですべての選択肢を考えたプログラムを作ることはできませんが、少なくとも機能的なシステムを非常に基本的な方法でインストールできるプログラムを作ることはできます。
インストールプロセスを理解する
BPMツールのおかげで、Gentooをコンピューターに正常にインストールするために必要な手順を理解できるプロセス図を生成できます。
自分の。 クリストファーディアスリベロス
いくつかのプロセスとサブプロセスが含まれているにもかかわらず、それは明らかにかなり要約されており、18の線形ステップがあることがわかります。 線形構造のアプリケーションは実装が簡単であると同時に、必要に応じてXNUMXつ以上のスレッドで並列処理を生成できるため、これは重要です。
もう一つの重要な要素は、それが私たちを可能にするということです 概要 タイプごとのプロセスのセット。たとえば、カーネルスレッドを定義すると、カーネルを正常にインストールするプロセスに直接関連する特定のタスクがスレッド内にあることがわかります。
自分の。 クリストファーディアスリベロス
このようにして、各「複雑な」ステップは、必要な詳細を失うことなく、グローバルな方法で「単純な」ステップになります。 これにより、プロセスを正常に完了するために必要な仕様のレベルを下げることなく、アセンブリの可視性が向上します。 また、ハンドブック全体を一度に読むよりも画像が見やすいことは否定できません🙂
時間を節約する
もうXNUMXつの明らかな利点は、直接接続されたプログラミング言語がないため、言語の実装に時間を浪費することなく論理分析を実行できることです。 これは、より効率的なソリューションがあるために機能が破棄されることを確認するためだけに機能の実装に費やすことができる時間と比較した場合の利点です。 擬似コードの解決策と同じように（多くの「開発者」によっても無視されているが、そうすべきではないもの）。
プロジェクトの指揮が簡単に
これらの概念を考慮に入れると、プロジェクト管理（あらゆる種類）が容易になります。これは、本当に必要な場所に注力するためです。この部分が正しく行われると、残りは自重になります。 それがあなたの好奇心を助け、BPM、アルゴリズム学、そして誰が知っているかについて研究する動機を与えることを願っています、多分それはあなたが私の論文で私を助けることを奨励するでしょう😛ここに来てくれてありがとう、そして私たちはすぐにお互いに会います。 よろしく
こんにちは。 あなたの知識を共有してくれてありがとう。 それはエキサイティングなテーマのように思えますが、それらを内面化できるようにするためには、多くの研究作業と概念の実践が必要です。 最初は、システムの要件を特定する側で問題を関連付ける傾向があり、必ずしも会社のビジネスプロセス、つまり会社の仕組みとは関係がないため、問題は混乱します。 結局のところ、ビジネスの運営をより効率的かつ効果的にするために、ソフトウェア開発者が会社のビジネスをモデル化する際に果たす役割についてだと思います。
こんにちはアレクサンダー、共有していただきありがとうございます。 実を言うと、このような小さなスペースにすべてを要約しようとするのはやや複雑なトピックですが、コメントとの混乱から抜け出すために少し貢献できれば🙂システムが要件を解決しようとするのは事実です。は最も可能な基本機能であり、その時点で、開発者はより高いレベルに焦点を合わせる必要があるのは事実です。
プロセスの知識により、開発者は十分な数のシステムを提示し、可能な限り最小限の要件を満たすものとして十分に理解することができます。
コードの優雅さは、プロセス全体を理解し、可能な限り最良のソリューションが適用されるより深い方法でコードを生成できることにあります。これは、よく述べたように、要件ではなくプロセスを実際に理解することによってのみ可能です。 🙂
FOSSを中心に少しモデル化すると、ソフトウェア要件だけでなく、その背後にある哲学、そしてそれがどのように維持されるか、誰によって、そして効率的なソリューションを生成するだけでなく、プロセスに関するすべての知識を知ることを意味します。 。、しかし、時間をかけて維持することは可能です🙂
どうもありがとうございました。