ソフトウェアエントロピーの説明：原因、影響、および対策
公開: 2022-03-11この記事は、ソフトウェアエントロピーとは何か、彼らの仕事への実際的な影響、およびその成長に寄与する根本的な要因について知りたいソフトウェア開発者またはプロジェクトマネージャーを対象としています。
主な目標は、ソフトウェアエントロピーがあらゆる形態のソフトウェア開発の要因であるため、ソフトウェアエントロピーの認識を高めることです。 さらに、ソフトウェアエントロピーに具体的な値を割り当てることができる手段を探ります。 ソフトウェアエントロピーを定量化し、連続するリリースでのその成長を観察することによってのみ、現在の目標と将来の計画にもたらすリスクを真に理解することができます。
ソフトウェアエントロピーとは何ですか？
ソフトウェアエントロピーは、現実世界のエントロピーの主な特徴からその名前が付けられています。これは、同じままであるか、時間の経過とともに増加するカオスの尺度です。 別の言い方をすれば、それは、ソフトウェアシステムの変更に関してソフトウェアシステムに組み込まれている固有の不安定性の尺度です。
残念ながら、ソフトウェアエントロピーがそれに値する重要性を与えられることはめったにありません。
開発チームから誰かを引き抜くとき、開発サイクルを時期尚早に開始するとき、または「迅速な修正」を実装するとき、つまり実際に成長する可能性が最も高い瞬間については考慮されません。
ソフトウェア開発は芸術であり、その中核となる構成要素が明確に定義されていない貿易です。 ビルダーはセメントと釘を使用しますが、ソフトウェア開発者は論理的なアサーションと一連の仮定を使用します。 これらを手に持って調べることも、8分の1インチ単位で注文することもできません。 カジュアルなオブザーバーは、ソフトウェア開発と構築を比較したくなるかもしれませんが、いくつかの表面的な類似点を超えて、そうすることは逆効果です。
これらの困難にもかかわらず、ソフトウェアエントロピーの原因を理解し、それが目的にもたらすリスクの程度を測定し、（必要に応じて）その成長を制限するためにどのような措置を講じることができるかを理解できるガイドラインを提示できます。
ソフトウェアエントロピーの提案された定義は次のとおりです。
ここで、
開発の反復の概念は、ソフトウェアエントロピーの理解に不可欠です。 これらは、システムのある動作から別の動作につながるアクティビティのサイクルです。 ソフトウェアの反復中に設定した目標は、スコープと呼ばれます。 ソフトウェア開発では、このようなサイクルには、ソフトウェアの基盤となるコードの変更または拡張が含まれます。
コードへのすべての変更は、それらを実行する人がそのように考えていなくても、開発の反復で発生します。 つまり、要件や分析の収集がほとんどまたはまったくない、「迅速で汚い」方法論を使用してシステムを構築することに誇りを持っている小規模な組織は、目標を達成するために開発の反復を使用します。 彼らは単にそれらを計画していません。 同様に、変更されたシステムの動作が私たちの意図から何らかの形で逸脱したとしても、それは開発の反復によって達成されました。
実際、これが発生するリスクは、ソフトウェアエントロピーに対する私たちの認識が説明することを意図したものであり、それを測定したいという私たちの願望が制限することを意図したものです。 したがって、実際には、ソフトウェアエントロピーを次のように定義できます。
どのシステムにも、既知の未解決の問題I0の有限集合があります。 次の開発イテレーションの終わりに、既知の未解決の問題I1の有限セットがあります。 システムの固有のエントロピーは、I 1の期待値が実際の値とどの程度異なる可能性があり、その後の反復でその差がどの程度大きくなる可能性があるかを指定します。
ソフトウェアエントロピーの影響
ソフトウェアエントロピーの影響に関する実際の経験は、問題のシステムとどのように相互作用するかによって異なります。
ユーザーはソフトウェアの静的なビューを持っています。 彼らはそれが現在どのように振る舞うかに関心があり、システムの内部については気にしません。 事前定義されたアクションを実行することにより、ユーザーは、ソフトウェアが対応する事前定義された動作で応答すると想定します。 ただし、ユーザーは、使用しているソフトウェアのエントロピーのレベルを推測する準備がほとんどできていません。
ソフトウェアエントロピーは変化の概念と結びついており、静的システムでは意味がありません。 システムを変更する意図がない場合、そのエントロピーについて話すことはできません。 同様に、まだ存在していないシステム（つまり、次の反復は実際にはその存在の最初のものです）にはエントロピーがありません。
ソフトウェアはユーザーの観点からは「バギー」と見なされる場合がありますが、その後の反復中にソフトウェア開発者と管理者が計画どおりに目標を達成している場合、システムのエントロピーは実際には非常に低いと結論付ける必要があります。 したがって、ユーザーの経験から、ソフトウェアのエントロピーについてはほとんどわかりません。
ソフトウェア開発者は、ソフトウェアについて流動的な見方をしています。 彼らは、システムを変更する必要がある場合にのみ、システムが現在どのように機能しているかに関心があり、適切な戦略を考案するためにシステムがどのように機能するかについての詳細に関心があります。
管理者は、静的および流動的なソフトウェアの両方について、おそらく最も複雑な見方をしています。 彼らは、短期間の緊急性と、さらに将来に及ぶ事業計画の要求とのバランスを取る必要があります。
これらの両方の役割の人々は期待を持っています。 ソフトウェアエントロピーは、それらの期待が台無しになるたびに現れます。 つまり、ソフトウェア開発者と管理者はリスクを評価して計画するために最善を尽くしますが、外部の混乱を除いて、それでも期待が失望している場合は、ソフトウェアエントロピーについて話すことができます。 範囲内になかったコンポーネントの相互作用を壊し、本番サーバーを不可解にクラッシュさせ、タイムリーで費用効果の高い修正プログラムを差し控えるのは見えざる手です。
高レベルのエントロピーを持つ多くのシステムは、特に開発チームのジュニアメンバーがいる場合、特定の個人に依存しています。 この人は、他の人が彼の「貴重な」入力なしに彼らのタスクを実行することができないような知識を持っています。 例外、ハンチ、およびヒントのアマルガムで構成されているため、標準のUML図または技術仕様に取り込むことはできません。 この知識は論理的に一貫したフレームワークに依存していないため、不可能ではないにしても、他の人に伝達することは困難です。
そのような組織は、多大な決意と努力をもって、自らを好転させ、IT部門を安定させることができると仮定しましょう。 ソフトウェア開発が停止したとき、どんな進歩も勇気づけられるので、状況は改善されたようです。 ただし、実際には、エントロピーがまだ低い間に到達可能であった高尚な目標と比較して、満たされる期待は低く、達成は面白くありません。
ソフトウェアエントロピーがプロジェクトを圧倒すると、プロジェクトはフリーズします。
これ以上の開発の反復はあり得ません。 幸い、この状況はすぐには発生しません。 崖の端に向かってゆっくりだが急な行進は、すべてのシステムが経験することです。 最初のバージョンがどれほど適切に編成され効率的であっても、連続する開発の反復にわたって、そのエントロピー、つまり予期せず問題が発生するリスクは、それを防ぐための特定の手順を実行しない限り大きくなります。
ソフトウェアのエントロピーを減らすことはできません。 現実世界のエントロピーと同じように、エントロピーは成長するか、同じままです。 最初は、その影響はごくわずかです。 それらが現れ始めると、症状は軽度であり、覆い隠すか無視することができます。 しかし、組織がソフトウェアエントロピーと戦うことを試みたのは、それがプロジェクトの主要なリスクになった後だけである場合、悲しいことに、その努力は無駄であることに気付くでしょう。 したがって、ソフトウェアエントロピーの認識は、その範囲が低く、悪影響が最小限である場合に最も役立ちます。
すべての組織がその製品のエントロピーの成長を制限するためにリソースを費やすべきであるということにはなりません。 今日開発されているソフトウェアの多く（特に消費者向けソフトウェア）の予想寿命は比較的短く、おそらく数年です。 この場合、システム全体が破棄される前に深刻な障害になることはめったにないため、その利害関係者はソフトウェアエントロピーの影響を考慮する必要はありません。 ただし、ソフトウェアエントロピーの影響を考慮する理由はそれほど明白ではありません。
インターネットのルーティングインフラストラクチャを実行したり、ある銀行口座から別の銀行口座に送金したりするソフトウェアについて考えてみましょう。 いつでも、このソフトウェアの1つ以上のバージョンが本番環境にあり、それらの集合的な動作をかなり高い精度で文書化できます。
システムのリスク許容度は、開発の反復ごとに快適に許可できる予期しない動作の量と種類の尺度です。 上記のタイプのシステムの場合、リスク許容度は、たとえば、電話をルーティングするソフトウェアよりもはるかに低くなります。 このソフトウェアは、多くの商用Webサイトのショッピングカートを駆動するソフトウェアよりもリスク許容度が低くなっています。
リスク許容度とソフトウェアエントロピーは、次の開発反復中にシステムのリスク許容範囲内にとどまるようにするために、ソフトウェアエントロピーを最小限に抑える必要があるという点で関連しています。
ソフトウェアエントロピーのソース
ソフトウェアエントロピーは、知識の欠如から生じます。 それは、私たちの共同の仮定と既存のシステムの実際の振る舞いとの間の相違から生じます。 この事実は、ソフトウェアエントロピーが既存のシステムを変更するという文脈でのみ意味を持つ理由を説明しています。 私たちの理解の欠如が実際的な効果をもたらすのはこれが唯一の時です。 ソフトウェアエントロピーは、システムの中で最も肥沃な場所を見つけます。その詳細は1人では理解できませんが、代わりに開発チーム全体に分散しています。 時間もまた、知識の強力な消しゴムです。
コードは、一連の論理アサーションの表現です。 ソフトウェアの動作（したがってそのコード）が、表現しようとしているロジックに対応していない場合、その固有のエントロピーについて話すことができます。 この状況は、次の3つの方法で発生する可能性があります。ロジックがよく知られており、その表現から逸脱している、コードが表現しようとしているロジックが複数理解されている、またはロジックがよく知られていない。
最初の状況（ロジックはよく知られており、現在の式とは異なります）は、対処するのが最も簡単ですが、最も一般的ではありません。 開発者とビジネスプランの責任者の2人の参加者によって維持されている非常に小さなシステムのみが、このカテゴリに分類されます。
2番目の状況（ロジックはよく知られていない）はまれです。 すべての意図と目的のために、開発の反復を開始することさえできません。 ある時点ですべての利害関係者が同意できる場合、最初の状況に直面する可能性があります。
人間の心はその経験を解釈し、それらを個人的なフレームワークに適合させるために効果的にフィルタリングおよび変更します。 アイデアの自由な交換、相互の尊重、明確な期待に基づく効果的な開発習慣がない場合、システムが現在どのように機能しているかについて、チームメンバーと同じくらい多くの解釈が存在する可能性があります。 現在の開発イテレーションに対するチームの目標自体が争われている可能性があります。
多くの開発者は、自分たちに何が必要であり、システムをどのように編成する必要があるかについての独自の理解を強化することにより、この状況から身を守ります。 一方、マネージャーやその他の利害関係者は、自分の生活を楽にするための誤った試みで、他のチームメンバーの想定を無意識のうちに変更しようとする可能性があります。
これで、ソフトウェアエントロピーの最も一般的なソースに到達しました。システムが表現しようとしているロジックには、複数の不完全な解釈があります。 この論理の現れは1つしかないため、状況は定義上問題があります。
この知識の欠如はどのようにして生じますか？ 無能は一つの方法です。 そして、すでに見てきたように、次の開発イテレーションの目標についての合意の欠如は別のものです。 しかし、考慮すべき他の要因があります。 組織は、開発方法論を採用することを主張するかもしれませんが、その後、フロア上のその側面の一部またはすべてを無計画に放棄します。 次に、ソフトウェア開発者は、多くの場合、解釈の余地のある漠然とした割り当てを完了する必要があります。 開発方法論の変更を実施している組織は、この現象に対して特に脆弱ですが、それが唯一の組織ではありません。 経営陣が気づいていない、または解決できない個人的な対立も、期待と結果の間に危険な相違をもたらす可能性があります。
製品に関する技術的知識を失う2つ目の、より重要な方法があります。それは転送中です。 紙に技術的な知識を取り込むことは、最も熟練した作家にとってさえ挑戦的です。 その理由は、何を転記するかは、どのように転記するかと同じくらい重要だからです。 適切な規律がないと、テクニカルライターはあまりにも多くの情報を記録する可能性があります。 あるいは、彼らは本質的なポイントを省略させるような仮定をするかもしれません。 作成された後、技術文書は細心の注意を払って最新の状態に保つ必要があります。これは、文書が作成されるとすぐに追跡できなくなる多くの組織にとって難しい提案です。 これらの困難さのために、技術的な知識がドキュメントだけで転送されることはめったにありませんが、ペアリングまたは他の形式の密接な人間同士の相互作用でも転送されます。
ソフトウェアエントロピーは、アクティブな参加者が開発チームを離れるたびに飛躍的に進歩します。 彼らは貴重なノウハウを持っています。 そのノウハウを複製することは不可能であり、それを概算するにはかなりの努力が必要です。 ただし、十分な注意とリソースがあれば、システムのエントロピーの増大を最小限に抑えることができる十分な知識が保持される可能性があります。
エントロピーの他のソースがありますが、これらは比較的マイナーです。 たとえば、ソフトウェアの腐敗は、システムが環境の変化によって予期せず影響を受けるプロセスです。 それが依存しているサードパーティのソフトウェア（ライブラリなど）を考えることはできますが、ソフトウェアの腐敗には他にももっと陰湿な原因があります。これは通常、システムの基礎となっている仮定の変更に起因します。 たとえば、システムがメモリの可用性について特定の仮定を持って設計されている場合、システムで使用可能なメモリが減少すると、予期しない瞬間にシステムが誤動作し始める可能性があります。
エントロピーを計算する方法：C、S、およびIに値を割り当てる
Iは、約束された機能がないことを含め、ソフトウェアシステムにおける未解決の動作上の問題の数です。 これは既知の量であり、JIRAなどのシステムで追跡されることがよくあります。 Iの値はそれから直接導き出されます。
Cは、スコープ内の作業単位が実装されたときに、次の反復での実際の未解決の問題I1の数が現在の見積もりよりも多くなるという認識された確率です。 この値は、ドメイン0 <= C<=1に存在します。
確率Cは、まさにソフトウェアエントロピーが測定しようとしているものであると主張する人もいるかもしれません。 ただし、この値とソフトウェアエントロピーの測定値には根本的な違いがあります。 何かがうまくいかないという認識された確率は、まさにそれです：それは実際の値ではありません。 しかし、プロジェクトに参加している人々の気持ちが、プロジェクトがどれほど安定しているかについての貴重な情報源であるという点で役立ちます。
スコープSは、提案された変更の大きさを考慮に入れており、Iと同じ単位で表す必要があります。提案された変更のスコープを拡大しているため、Sの値を大きくすると、エントロピーが減少します。 これは直感に反するように聞こえるかもしれませんが、エントロピーはシステムの開発が私たちの期待にどのように応えられないかを示す尺度であることに留意する必要があります。 エントロピーが問題を引き起こす可能性の尺度であると言うだけでは十分ではありません。 私たちは自然にリスクを予測し、計画の際にそれらを考慮に入れます（したがって、I1の推定では、 0を超えて増加する可能性があります）。 明らかに、私たちが大きな変更範囲に取り組むことに自信を持っているほど、変更を計画したり実行したりする人が無能でない限り、システム内のエントロピーは少ないと言えます。 ただし、この可能性は、おそらく
I1の実際の値とその期待値の差の大きさを指定する必要はないことに注意してください。 計画を立てるときに計画が正しいと仮定した場合、結果が期待を満たさない程度を予測できると仮定することも合理的ではありません。 指定できるのは、認識されたチャンスCだけです。 ただし、実際の値I 1が期待値とどの程度異なるかは、派生値
理論的には、Iが負の値になる可能性があります。 ただし、実際には、このような状況は発生しません。 私たちは通常、誤って問題を解決することはありません。
Cは主観的な値です。 これは、開発イテレーションの参加者の心の中に存在し、それらをポーリングして結果を平均することで推測できます。 質問は前向きに行われるべきです。 例： 「0から10のスケールで、10の可能性が最も高い場合、この開発の反復でチームのすべての目標を達成する可能性をどのように推定しますか？」
サブセットではなく、チーム全体の目的について質問が提起されていることに注意してください。 10の応答はCの値0を示し、7の応答は0.3の値を示します。 大規模なチームでは、個人がプロジェクトに関与した期間や実際にプロジェクトに費やされた時間など、関連する要因に応じて各応答に重みが付けられる場合があります。 ただし、能力は、応答を重み付けする際の要因であってはなりません。 やがて、チームのジュニアメンバーでさえ、その目的を達成する上でどれほど効果的であるかを実感できるようになります。 十分に大規模なチームは、残りを平均化する前に、報告された最高値と最低値を破棄したい場合があります。
チームが失敗する可能性を専門家に尋ねることは、敏感で挑発的な提案です。 ただし、これはまさに、エントロピーを定量化することを望む組織が尋ねる必要のある質問です。 正直な回答を確実にするために、参加者は、たとえ非常に高い値を報告したとしても、Cの推定値を匿名で、影響を恐れずに提供する必要があります。
Sには、
ホットフィックスやその他の本番環境への予定外のリリースは、開発イテレーションの範囲を定義するものとは見なさないことに注意してください。また、関連するストーリーを
このアプローチの難しさは、バグを後でストーリーに分解する前に、発見と分析の期間を発生させる必要があることです。 したがって、Iの真の値は、遅延後にのみ定義できます。 さらに、Cのポーリングは、各スプリントの開始時に自然に発生します。 したがって、得られた結果は、リリース全体のスパンにわたってもう一度平均化する必要があります。 これらの困難にもかかわらず、アジャイル手法の側面を採用しているチームは、ストーリーがS（したがって
現在使用されている他の開発方法論があります。 採用する方法が何であれ、ソフトウェアエントロピーを測定するための原則は同じです。ソフトウェアエントロピーはリリースから本番環境まで測定する必要があり、SとIは同じ「作業単位」で測定する必要があり、Cの推定値は脅迫的ではなく、できれば匿名の方法。
Eの成長を減らす
システムに関する知識が失われると、それを取り戻すことはできません。 このため、ソフトウェアのエントロピーを減らすことはできません。 私たちにできることは、その成長を抑えることだけです。
ソフトウェア開発中に適切な手段を採用することにより、エントロピーの成長を制限することができます。 アジャイル開発のペアプログラミングの側面は、この点で特に役立ちます。 コードの記述時には複数の開発者が関与しているため、重要な詳細に関する知識が配布され、チームメンバーを離れる影響が軽減されます。
もう1つの有用な方法は、特にウォーターフォール手法を採用している組織内で、適切に構造化され、簡単に使用できるドキュメントを作成することです。 このような文書は、すべての人が理解している厳密で明確な原則に裏打ちされている必要があります。 コミュニケーションの主要な手段として文書化に依存し、技術的知識を保護する組織は、このアプローチに非常に適しています。 RADまたはアジャイル手法を採用している若い組織でよくあることですが、内部で作成されたドキュメントを作成および使用する方法に関するガイドラインやトレーニングがない場合にのみ、その価値が疑わしくなります。
システムのエントロピーの増加を減らすには、2つの方法があります。Iを減らすこと
1つ目は、リファクタリングです。 私を減らすことを目的とした行動は、本質的に技術的である傾向があり、おそらく読者にはすでになじみがあります。 開発の反復が発生する必要があります。 エントロピーの成長を減らすことを目的としたこの反復の部分は、時間とリソースを消費しますが、具体的なビジネス上のメリットはありません。 この事実により、多くの場合、エントロピーの成長を抑えることは、どの組織でも難しい販売になります。
Cの値を減らすことは、効果がより長期的であるため、より強力な戦略です。 さらに、CはIとSの比率の成長に対する重要なチェックとして機能します。Cを減らすためのアクションは、人間の行動と思考に焦点を当てる傾向があります。 これらのアクション自体は開発の反復を必要としない場合がありますが、参加者が新しい手順を受け入れて調整するため、後続の反復は遅くなります。 プロジェクトの参加者と利害関係者の異なる目標が突然明らかになるので、どのような改善を行うべきかについて合意するという一見単純な行為は、それ自体が危険に満ちた道です。
まとめ
ソフトウェアエントロピーは、既存のソフトウェアを変更すると、予期しない問題、達成されていない目的、またはその両方が発生するリスクです。
ソフトウェアが最初に作成されたときには無視できますが、ソフトウェアのエントロピーは開発の反復ごとに大きくなります。 チェックせずに続行することを許可された場合、ソフトウェアエントロピーは最終的にさらなる開発を停止させます。
ただし、すべてのプロジェクトがソフトウェアエントロピーの影響を考慮に入れる必要はありません。 エントロピーが顕著で有害な影響を与える前に、多くのシステムが生産から除外されます。 エントロピーが信頼できるリスクをもたらすほど寿命が長い人にとっては、エントロピーに対する認識を高め、その範囲を測定することは、まだ低いうちに、開発が時期尚早に中断されないようにする手段を提供します。
システムがソフトウェアエントロピーの影響に完全に圧倒されると、それ以上の変更はできなくなり、開発は本質的に終了します。