プロジェクト管理

ソフトウェアエントロピーの説明：原因、影響、および対策

この記事は、ソフトウェアエントロピーとは何か、彼らの仕事への実際的な影響、およびその成長に寄与する根本的な要因について知りたいソフトウェア開発者またはプロジェクトマネージャーを対象としています。

主な目標は、 ソフトウェアエントロピーの認識 それはあらゆる形態のソフトウェア開発の要因だからです。さらに、ソフトウェアエントロピーに具体的な値を割り当てることができる手段を探ります。ソフトウェアエントロピーを定量化し、その後のリリースでのその成長を観察することによってのみ、現在の目標と将来の計画にもたらすリスクを真に理解することができます。

ソフトウェアエントロピーとは何ですか？

ソフトウェアエントロピー 実世界のエントロピーの主な特徴からその名前が付けられました。 これは、同じままであるか、時間の経過とともに増加するカオスの尺度です。 。別の言い方をすれば、それは、ソフトウェアシステムの変更に関してソフトウェアシステムに組み込まれている固有の不安定性の尺度です。

残念ながら、ソフトウェアエントロピーがそれに値する重要性を与えられることはめったにありません。

開発チームから誰かを引き抜くとき、開発サイクルを時期尚早に開始するとき、または「迅速な修正」を実装するとき、つまり実際に成長する可能性が最も高い瞬間については考慮されません。

ソフトウェア開発は芸術と貿易であり、そのコアビルディングブロックは明確に定義されていません。ビルダーはセメントと釘を使用しますが、ソフトウェア開発者は論理的なアサーションと一連の仮定を使用します。これらを手に持って調べることも、8分の1インチ単位で注文することもできません。カジュアルな観察者は、ソフトウェア開発と構築を比較したくなるかもしれませんが、いくつかの表面的な類似点を超えて、そうすることは逆効果です。

水平線の画像。反復ごとに混沌とし、線のようになりません。

これらの困難にもかかわらず、ソフトウェアエントロピーの原因を理解し、それが目的にもたらすリスクの程度を測定し、（必要に応じて）その成長を制限するためにどのような手順を実行できるかを理解できるガイドラインを提示できます。

ソフトウェアエントロピーの提案された定義は次のとおりです。

E = I´C / S

ここで、I´は、最後の開発反復中に導入された予期しない問題の数から導き出されます。Cは、システムに変更を実装すると、新しいI´> 0になる確率として認識され、Sは次の開発反復の範囲です。一般に、0.1未満のEの値は適切と見なされます。 0.5のEは高いと見なされ、1.0を超える値は圧倒的です。

の概念 開発の反復 ソフトウェアエントロピーの理解に不可欠です。これらは、システムのある動作から別の動作につながるアクティビティのサイクルです。ソフトウェアの反復中に設定した目標は、範囲。ソフトウェア開発では、このようなサイクルには、ソフトウェアの基盤となるコードの変更または拡張が含まれます。

コードへのすべての変更は、それらを実行する人がそのように考えていなくても、開発の反復で発生します。つまり、要件や分析をほとんどまたはまったく収集せずに、「迅速で汚い」方法論を使用してシステムを構築することに誇りを持っている小規模な組織は、目標を達成するために開発の反復を使用します。彼らは単にそれらを計画していません。同様に、変更されたシステムの動作が私たちの意図から何らかの形で逸脱したとしても、それは開発の反復によって達成されました。

実際、これが発生するリスクは、ソフトウェアエントロピーの認識が説明することを意図したものであり、それを測定したいという願望が制限することを意図したものです。したがって、実際には、ソフトウェアエントロピーを次のように定義できます。

特定のシステムには、既知の未解決の問題の有限セットがあります。₀。次の開発イテレーションの終わりに、既知の未解決の問題の有限セットがあります。₁。システムの固有のエントロピーは、私たちがどれだけ私に期待するかを指定します₁実際の値とは異なる可能性があり、その後の反復でその差がどの程度大きくなる可能性があります。

ソフトウェアエントロピーの影響

ソフトウェアエントロピーの影響に関する実際の経験は、問題のシステムとどのように相互作用するかによって異なります。

ユーザーはソフトウェアの静的なビューを持っています。彼らはそれが現在どのように動作するかに関心があり、システムの内部については気にしません。事前定義されたアクションを実行することにより、ユーザーは、ソフトウェアが対応する事前定義された動作で応答すると想定します。ただし、ユーザーは、使用しているソフトウェアのエントロピーのレベルを推測する準備がほとんどできていません。

どのタイプのWebベースの攻撃がhtmlフォームのgetおよびpost関数を使用しますか？

ソフトウェアエントロピーは変化の概念と結びついており、静的システムでは意味がありません。システムを変更する意図がない場合、そのエントロピーについて話すことはできません。同様に、まだ存在していないシステム（つまり、次の反復は実際にはその存在の最初のものです）にはエントロピーがありません。

ソフトウェアはユーザーの観点からは「バギー」と見なされる場合がありますが、その後の反復中にソフトウェア開発者と管理者が計画どおりに目標を達成している場合、システムのエントロピーは実際には非常に低いと結論付ける必要があります。したがって、ユーザーの経験から、ソフトウェアのエントロピーについてはほとんどわかりません。

ソフトウェア開発者は、ソフトウェアについて流動的な見方をしています。彼らは、システムを変更する必要がある場合にのみ、システムが現在どのように機能しているかに関心があり、適切な戦略を考案するためにシステムがどのように機能するかの詳細に関心があります。
管理者は、静的および流動的なソフトウェアについて、おそらく最も複雑な見方をしています。彼らは、短期間の緊急性と、さらに将来に及ぶ事業計画の要求とのバランスを取る必要があります。

これらの両方の役割の人々は期待を持っています。ソフトウェアエントロピーは、それらの期待が損なわれるたびに現れます。つまり、ソフトウェア開発者と管理者はリスクを評価して計画するために最善を尽くしますが、外部の混乱を除いて、それでも期待が失望している場合は、ソフトウェアエントロピーについて話すことができます。スコープ内になかったコンポーネントの相互作用を壊し、本番サーバーを不可解にクラッシュさせ、タイムリーで費用対効果の高い修正プログラムを差し控えるのは見えざる手です。

複雑なシステムのイメージ多くの要素と接続

高レベルのエントロピーを持つ多くのシステムは、特に開発チームのジュニアメンバーがいる場合、特定の個人に依存しています。この人は、他の人が彼の「貴重な」入力なしに彼らのタスクを実行することができないような知識を持っています。例外、ハンチ、およびヒントのアマルガムで構成されているため、標準のUML図または技術仕様に取り込むことはできません。この知識は論理的に一貫したフレームワークに依存していないため、不可能ではないにしても、他の人に伝達することは困難です。

そのような組織は、多大な決意と努力をもって、自らを好転させ、IT部門を安定させることができると仮定しましょう。ソフトウェア開発が停止したとき、どんな進歩も勇気づけられるので、状況は改善されたようです。しかし、実際には、エントロピーがまだ低い間に到達可能であった高い目標と比較して、達成される期待は低く、達成は面白くありません。

ソフトウェアエントロピーがプロジェクトを圧倒すると、プロジェクトはフリーズします。

これ以上の開発の反復はあり得ません。幸いなことに、この状況はすぐには発生しません。崖の端に向かってゆっくりだが急な行進は、すべてのシステムが経験するものです。最初のバージョンがどれほど適切に編成され効率的であったとしても、連続する開発の反復にわたって、そのエントロピー、つまり予期せぬ事態が発生するリスクは、それを防ぐための特定の措置を講じない限り増大します。

ソフトウェアのエントロピーを減らすことはできません。 現実世界のエントロピーと同じように、それは成長するか、同じままです。最初は、その影響はごくわずかです。それらが現れ始めると、症状は軽度であり、覆い隠すか無視することができます。しかし、組織がプロジェクトで支配的なリスクになった後でのみソフトウェアエントロピーと戦おうとすると、悲しいことに、その努力は無駄になります。したがって、ソフトウェアエントロピーの認識は、その範囲が低く、悪影響が最小限である場合に最も役立ちます。

すべての組織がその製品のエントロピーの成長を制限するためにリソースを費やすべきであるということにはなりません。今日開発されているソフトウェアの多く（特に消費者向けソフトウェア）の予想寿命は比較的短く、おそらく数年です。この場合、システム全体が破棄される前に深刻な障害になることはめったにないため、利害関係者はソフトウェアエントロピーの影響を考慮する必要はありません。ただし、ソフトウェアエントロピーの影響を考慮する理由はそれほど明白ではありません。

インターネットのルーティングインフラストラクチャを実行したり、ある銀行口座から別の銀行口座に送金したりするソフトウェアについて考えてみましょう。いつでも、このソフトウェアの1つ以上のバージョンが本番環境にあり、それらの集合的な動作をかなり高い精度で文書化できます。

ザ・ リスク許容度 システムのは、ある開発の反復から次の反復まで、快適に許可できる予期しない動作の量と種類の尺度です。上記のタイプのシステムの場合、リスク許容度は、たとえば、電話をルーティングするソフトウェアよりもはるかに低くなります。このソフトウェアは、多くの商用Webサイトのショッピングカートを駆動するソフトウェアよりもリスク許容度が低くなっています。

リスク許容度とソフトウェアエントロピーは、次の開発反復中にシステムのリスク許容範囲内にとどまるようにするために、ソフトウェアエントロピーを最小限に抑える必要があるという点で関連しています。

ソフトウェアエントロピーのソース

ソフトウェアエントロピーは 知識の欠如 。それは、私たちの共同の仮定と既存のシステムの実際の振る舞いとの間の相違から生じます。この事実は、ソフトウェアエントロピーが既存のシステムを変更するという文脈でのみ意味を持つ理由を説明しています。私たちの理解の欠如が実際的な効果をもたらすのはこれだけです。ソフトウェアエントロピーは、システムの中で最も肥沃な土地を見つけます。その詳細は1人では理解できませんが、代わりに開発チーム全体に分散しています。時間もまた、知識の強力な消しゴムです。

コードは、一連の論理アサーションの表現です。ソフトウェアの動作（したがってそのコード）が、表現しようとしているロジックに対応していない場合、その固有のエントロピーについて話すことができます。この状況は、次の3つの方法で発生する可能性があります。ロジックがよく知られており、その表現から逸脱している、コードが表現しようとしているロジックが複数理解されている、またはロジックがよく知られていない。

知識の欠如、発散論理、および未知の論理の図

最初の状況— 論理はよく知られています 現在の表現とは異なります。対処するのが最も簡単ですが、最も一般的ではありません。開発者とビジネスプランの責任者の2人の参加者によって維持されている非常に小さなシステムのみが、このカテゴリに分類されます。
2番目の状況— 論理はよく知られていない —まれです。すべての意図と目的のために、開発の反復を開始することさえできません。ある時点ですべての利害関係者が同意できる場合、最初の状況に直面する可能性があります。

人間の精神はその経験を解釈し、それらを個人的なフレームワークに適合させるために効果的にフィルタリングおよび変更します。アイデアの自由な交換、相互尊重、明確な期待に基づく効果的な開発習慣がない場合、システムが現在どのように機能しているかについて、チームメンバーと同じくらい多くの解釈が存在する可能性があります。現在の開発イテレーションに対するチームの目標自体が争われている可能性があります。

多くの開発者は、自分たちに何が必要であり、システムをどのように編成する必要があるかについての独自の理解を強化することにより、この状況から身を守ります。一方、マネージャーやその他の利害関係者は、自分の生活を楽にするための誤った試みで、他のチームメンバーの想定を無意識のうちに変更しようとする可能性があります。

これで、ソフトウェアエントロピーの最も一般的なソースに到達しました。 システムが表現しようとしている論理には、複数の不完全な解釈があります。 この論理の兆候は1つしかないため、状況は定義上問題があります。

この知識の欠如はどのようにして生じますか？無能は一つの方法です。そして、すでに見てきたように、次の開発イテレーションの目標についての合意の欠如は別の問題です。しかし、考慮すべき他の要因があります。組織は、開発方法論を採用すると主張するかもしれませんが、その後、フロア上のその側面の一部またはすべてを無計画に放棄します。次に、ソフトウェア開発者は、あいまいな割り当てを完了する必要があり、多くの場合、解釈の余地があります。開発方法の変更を実装している組織は、この現象に対して特に脆弱ですが、それだけではありません。経営陣が気づいていない、または解決できない個人的な対立も、期待と結果の間に危険な相違をもたらす可能性があります。

製品に関する技術的知識を失う2つ目の、より重要な方法があります。それは転送中です。紙に技術的な知識を取り込むことは、最も熟練した作家にとってさえ挑戦的です。その理由は何転写することは同じくらい重要です どうやって 。適切な規律がないと、テクニカルライターはあまりにも多くの情報を記録する可能性があります。あるいは、彼らは本質的なポイントを省略させるような仮定をするかもしれません。作成された後、技術文書は細心の注意を払って最新の状態に保つ必要があります。これは、文書が作成されるとすぐに追跡できなくなる多くの組織にとって難しい提案です。これらの困難さのために、技術的知識がドキュメントだけで転送されることはめったにありませんが、ペアリングまたは他の形式の密接な人間間相互作用でも転送されます。

ソフトウェアエントロピーは、アクティブな参加者が開発チームを離れるたびに飛躍的に進歩します。彼らは貴重なノウハウを持っています。そのノウハウを複製することは不可能であり、それを概算するにはかなりの努力が必要です。ただし、十分な注意とリソースがあれば、システムのエントロピーの増大を最小限に抑えることができる十分な知識が保持される可能性があります。

エントロピーには他にも原因がありますが、これらは比較的マイナーです。たとえば、ソフトウェアの腐敗は、システムが環境の変化によって予期せず影響を受けるプロセスです。それが依存しているサードパーティのソフトウェア（ライブラリなど）を考えることはできますが、ソフトウェアの腐敗には他にももっと陰湿な原因があります。これは通常、システムの基礎となっている仮定の変更に起因します。たとえば、システムがメモリの可用性について特定の仮定を持って設計されている場合、システムで使用可能なメモリが減少すると、予期しない瞬間に誤動作を開始する可能性があります。

エントロピーを計算する方法：C、S、およびIに値を割り当てる

Iは、約束された機能がないことを含め、ソフトウェアシステムにおける未解決の動作上の問題の数です。これは既知の量であり、次のようなシステムで追跡されることがよくあります。 JIRA 。 I´の値はそれから直接導き出されます。 I´は、新しく導入された予期しない動作の問題に起因する作業単位の数に加えて、最後の開発反復中に放棄または不完全なままにされた「作業単位」の数です。 I´は作業単位の数としてカウントされるため、同じ作業単位での次の開発反復のスコープであるSの値に関連付けることができます。「ワークユニット」を正確に構成するものは、開発方法に依存します。

Cは、スコープ内の作業単位が実装されたときに、次の反復での実際の未解決の問題I1の数が現在の見積もりよりも多くなるという認識された確率です。この値はドメイン0に存在します<= C <= 1.

確率Cは、まさにソフトウェアエントロピーが測定しようとしているものであると主張する人もいるかもしれません。ただし、この値とソフトウェアエントロピーの測定値には根本的な違いがあります。ザ・知覚何かがうまくいかない確率はまさにそれです：それは本当の価値ではありません。しかし、プロジェクトに参加している人々の気持ちが、プロジェクトがどれほど安定しているかについての貴重な情報源であるという点で役立ちます。

スコープSは、提案された変更の大きさを考慮に入れており、I´と同じ単位で表す必要があります。 Sの値を大きくすると、提案された変更の範囲が拡大するため、エントロピーが減少します。これは直感に反するように聞こえるかもしれませんが、エントロピーはシステムの開発がどのように行われるかを示す尺度であることに留意する必要があります。ない私たちの期待に応えます。エントロピーが問題を引き起こす可能性の尺度であると言うだけでは十分ではありません。私たちは自然にリスクを予測し、計画でそれらを考慮に入れます（したがって、I1の推定では、リスクが₀）。明らかに、大きな変更範囲を採用することに自信があればあるほど、変更を計画したり実行したりする人が無能でない限り、システム内のエントロピーは少ないと言えます。ただし、この可能性は、おそらくI´の現在の値に反映されています。

Iの実際の値との差の大きさを指定する必要はないことに注意してください。₁とその期待値。計画を立てるときに計画が正しいと仮定した場合、結果が期待を満たさない程度を予測できると仮定することも合理的ではありません。指定できるのは、認識されたチャンスCだけです。ただし、実際の値Iの程度₁期待値とは異なるのは、次の反復でのエントロピーの計算への重要な入力であり、派生値I´の形式です。

理論的には、I´が負の値になる可能性があります。ただし、実際には、このような状況は発生しません。私たちは通常、誤って問題を解決することはありません。 I´の負の値は慰めの兆候ではありません。それらは、エントロピーが計算されている手段に欠陥があることを意味します。もちろん、ソフトウェアエントロピーの増加は、以下に説明するように、特定の対策を講じることによって減らすことができます。ただし、そのような場合、私たちは常に期待を設計に組み込んでいるため、負の値を想定するべきではありません。

画像の4つのバージョンの画像で、連続する各バージョンにはより多くのエラーが含まれています

Cは主観的な値です。これは、開発イテレーションの参加者の心の中に存在し、それらをポーリングして結果を平均することで推測できます。質問は前向きな方法で尋ねられるべきです。例えば： 「0から10のスケールで、最も可能性が高いのは10ですが、この開発の反復でチームがすべての目標を達成する可能性をどのように見積もりますか？」

質問は、サブセットではなく、チームの目的全体について提起されていることに注意してください。 10の応答はCの値0を示し、7の応答は.3の値を示します。大規模なチームでは、各応答は、個人がプロジェクトに関与していた期間や実際にプロジェクトに費やされた時間など、関連する要因に応じて重み付けされる場合があります。ただし、能力は応答の重み付けの要因となるべきではありません。やがて、チームのジュニアメンバーでさえ、その目的を達成するのにどれほど効果的であるかを感じるようになるでしょう。十分に大規模なチームは、残りを平均化する前に、報告された最高値と最低値を破棄したい場合があります。

チームが失敗する可能性がどの程度あるかを専門家に尋ねることは、敏感で挑発的な提案です。ただし、これはまさに、エントロピーを定量化したい組織が尋ねる必要のある質問です。正直な回答を確実にするために、参加者は、たとえ非常に高い値を報告したとしても、匿名で、影響を恐れずにCの推定値を与える必要があります。

Sには、I´と同じ「作業単位」で値を割り当てる必要があるため、開発方法に大きく依存します。の側面を採用するチームの場合アジャイル手法、ストーリーはSとI´の両方にとって最も明白な「作業単位」のようです。この場合、開発イテレーションの範囲は、マイナーまたはメジャーのいずれかで、定期的にスケジュールされた各リリースから本番環境にまで及びます。 I´は、リリースに至るまでの各スプリント中に正常に完了しなかったストーリーの数と、リリース後に明らかになった予期しない問題の結果として将来のスプリントに含めるために生成されたストーリーの数の合計として定量化する必要があります。

ホットフィックスやその他の本番環境への予定外のリリースは、開発の反復の範囲を定義するものとは見なさず、関連するストーリーをI´から差し引くべきでもないことに注意してください。

このアプローチの難しさは、バグを後でストーリーに分解する前に、発見と分析の期間を発生させる必要があることです。したがって、I´の真の値は、遅延後にのみ定義できます。さらに、Cのポーリングは、各スプリントの開始時に自然に発生します。したがって、得られた結果は、リリース全体にわたってもう一度平均化する必要があります。これらの困難にもかかわらず、アジャイル手法の側面を採用しているチームは、ストーリーがS（したがってI´）を定量化するための最も正確な単位であることに気付く可能性があります。

今日使用されている他の開発方法論があります。採用する方法が何であれ、ソフトウェアエントロピーを測定するための原則は同じです。ソフトウェアエントロピーはリリースから本番環境まで測定する必要があり、SとI´は同じ「作業単位」で測定する必要があり、Cの見積もりは直接参加者から取得する必要があります。脅迫的ではなく、できれば匿名の方法で。

Eの成長を減らす

システムに関する知識が失われると、それを取り戻すことはできません。このため、ソフトウェアのエントロピーを減らすことはできません。私たちにできることは、その成長を抑えることだけです。

ソフトウェア開発中に適切な手段を採用することにより、エントロピーの成長を制限することができます。アジャイル開発のペアプログラミングの側面は、この点で特に役立ちます。コードの作成時には複数の開発者が関与しているため、重要な詳細に関する知識が配布され、チームメンバーを離れる影響が軽減されます。

もう1つの有用な方法は、特にウォーターフォール手法を採用している組織内で、適切に構造化され、簡単に使用できるドキュメントを作成することです。このような文書は、誰もが理解できる厳密で明確な原則に裏打ちされている必要があります。コミュニケーションの主要な手段として文書化に依存し、技術的知識を保護する組織は、このアプローチに非常に適しています。ある時だけです番号 RADまたはアジャイル手法を採用している若い組織でよくあることですが、内部で作成されたドキュメントを作成および使用する方法に関するガイドラインまたはトレーニングでは、その価値が疑わしいものになります。

システム内のエントロピーの増加を減らすには、2つの方法があります。I´を減らすことを目的とした変更を実行するか、Cを減らすことを目的とした変更を実行します。

1つ目は、リファクタリングです。 I´を減らすことを目的としたアクションは、本質的に技術的な傾向があり、おそらく読者にはすでになじみがあります。開発の反復が発生する必要があります。エントロピーの成長を減らすことを目的としたこの反復の部分 目に見えるビジネス上のメリットはありません 時間とリソースを消費しますが。この事実により、エントロピーの増加を抑えることは、どの組織でも難しい販売になります。

Cの値を減らすことは、効果がより長期的であるため、より強力な戦略です。さらに、CはI´とSの比率の増加に対する重要なチェックとして機能します。Cを減らすための行動は、人間の行動と思考に焦点を合わせる傾向があります。これらのアクション自体は開発の反復を必要としない場合がありますが、参加者が新しい手順を受け入れて調整するため、後続の反復が遅くなります。プロジェクトの参加者と利害関係者の異なる目標が突然明らかになるため、どのような改善を行うべきかについて合意するという一見単純な行為は、それ自体が危険に満ちた道です。

まとめ

ソフトウェアエントロピーは、既存のソフトウェアを変更すると、予期しない問題、達成されていない目的、またはその両方が発生するリスクです。

ソフトウェアが最初に作成されたときには無視できますが、ソフトウェアのエントロピーは開発の反復ごとに大きくなります。チェックせずに続行することを許可された場合、ソフトウェアエントロピーは最終的にさらなる開発を停止させます。

ただし、すべてのプロジェクトがソフトウェアエントロピーの影響を考慮に入れる必要があるわけではありません。多くのシステムは、エントロピーが目立って有害な影響を与える前に、生産から除外されます。エントロピーが信頼できるリスクをもたらすほど寿命が長い人にとっては、エントロピーに対する認識を高め、その範囲を測定することは、まだ低いうちに、開発が時期尚早に中断されないようにする手段を提供します。

システムがソフトウェアエントロピーの影響に完全に圧倒されると、それ以上の変更はできなくなり、開発は本質的に終了します。