소프트웨어 엔트로피 설명: 원인, 결과 및 해결 방법

이 기사는 소프트웨어 엔트로피가 무엇인지, 작업에 대한 실질적인 영향, 소프트웨어 엔트로피의 성장에 기여하는 기본 요소에 대해 궁금한 소프트웨어 개발자 또는 프로젝트 관리자를 대상으로 합니다.

주요 목표는 소프트웨어 엔트로피가 모든 형태의 소프트웨어 개발 요소이기 때문에 소프트웨어 엔트로피에 대한 인식 을 만드는 것입니다. 또한 소프트웨어 엔트로피에 구체적인 값을 할당할 수 있는 방법을 탐구합니다. 소프트웨어 엔트로피를 수량화하고 연속 릴리스에 대한 성장을 관찰해야만 현재 목표와 미래 계획에 미치는 위험을 진정으로 이해할 수 있습니다.

소프트웨어 엔트로피란?

소프트웨어 엔트로피 는 현실 세계에서 엔트로피의 주요 특성에서 그 이름을 얻었습니다. 이는 동일하게 유지되거나 시간이 지남에 따라 증가하는 혼돈의 척도입니다 . 달리 말하면, 소프트웨어 시스템을 변경하는 것과 관련하여 소프트웨어 시스템에 내장된 고유한 불안정성의 척도입니다.

불행히도 소프트웨어 엔트로피는 그 중요성이 거의 인정되지 않습니다.

개발 팀에서 누군가를 빼내거나, 개발 주기를 조기에 시작하거나, 실제로 성장할 가능성이 가장 높은 "빠른 수정"을 구현할 때 고려되지 않습니다.

소프트웨어 개발은 ​​핵심 빌딩 블록이 잘못 정의된 예술이자 거래입니다. 빌더는 시멘트와 못으로 작업하지만 소프트웨어 개발자는 논리적 주장과 일련의 가정으로 작업합니다. 이것들은 손에 들고 검사할 수도 없고 8분의 1인치 단위로 주문할 수도 없습니다. 우연한 관찰자는 소프트웨어 개발을 건설과 비교하고 싶은 유혹을 받을 수 있지만, 몇 가지 피상적인 유사성을 넘어서는 비생산적입니다.

이러한 어려움에도 불구하고 우리는 소프트웨어 엔트로피의 근원을 이해하고, 그것이 우리 목표에 제기하는 위험의 정도를 측정하고, 필요한 경우 성장을 제한하기 위해 어떤 조치를 취할 수 있는지에 대한 지침을 제시할 수 있습니다.

제안된 소프트웨어 엔트로피 정의는 다음과 같다.

여기서 I 은 마지막 개발 반복 중에 도입된 예상치 못한 문제의 수에서 파생되고, C는 시스템 변경을 구현하면 이제 새로운 I > 0이 발생할 수 있는 인지된 확률이며, S는 다음 개발 반복의 범위입니다. 일반적으로 0.1 미만의 E 값은 양호한 것으로 간주됩니다. 0.5의 E는 높은 것으로 간주되며 1.0 이상의 값은 압도적입니다.

개발 반복 의 개념은 소프트웨어 엔트로피를 이해하는 데 필수적입니다. 이것은 시스템의 한 동작에서 다른 동작으로 이어지는 활동 주기입니다. 소프트웨어 반복 중에 설정한 목표를 범위 라고 합니다. 소프트웨어 개발에서 이러한 주기에는 소프트웨어의 기본 코드를 수정하거나 확장하는 작업이 포함됩니다.

코드에 대한 모든 수정은 수행하는 사람들이 그렇게 생각하지 않더라도 개발 반복에서 발생합니다. 즉, 요구 사항이나 분석을 거의 또는 전혀 수집하지 않고 "빠르고 더러운" 방법론을 사용하여 시스템을 구축하는 데 자부심을 느끼는 소규모 조직은 여전히 ​​목표를 달성하기 위해 개발 반복을 사용합니다. 그들은 단순히 계획하지 않습니다. 마찬가지로, 수정된 시스템의 동작이 우리의 의도와 어떤 면에서 벗어나더라도 개발 반복을 통해 여전히 달성되었습니다.

사실, 이것이 일어날 위험은 소프트웨어 엔트로피에 대한 우리의 인식이 설명하고자 하는 것이고 그것을 측정하고자 하는 우리의 욕망이 제한하려는 것입니다. 따라서 실용적인 용어로 소프트웨어 엔트로피를 다음과 같이 정의할 수 있습니다.

주어진 모든 시스템에는 알려진 미해결 문제 I ₀ 의 유한 집합이 있습니다. 다음 개발 반복이 끝나면 유한한 일련의 알려진 공개 문제 I ₁ 가 있을 것입니다. 시스템의 고유한 엔트로피는 I ₁ 에 대한 우리의 기대가 실제 값과 얼마나 다를지 그리고 그 차이가 후속 반복에서 얼마나 커질 것인지를 지정합니다.

소프트웨어 엔트로피의 영향

소프트웨어 엔트로피 효과에 대한 실제 경험은 문제의 시스템과 상호 작용하는 방식에 따라 다릅니다.

사용자는 소프트웨어에 대해 정적인 관점을 가지고 있습니다. 그들은 그것이 지금 어떻게 행동하는지에 관심이 있고 시스템의 내부에는 관심이 없습니다. 사전 정의된 작업을 수행함으로써 사용자는 소프트웨어가 사전 정의된 해당 동작으로 응답할 것이라고 가정합니다. 그러나 사용자는 사용 중인 소프트웨어의 엔트로피 수준을 추론할 준비가 거의 되어 있지 않습니다.

소프트웨어 엔트로피는 변화의 개념과 연결되어 있으며 정적 시스템에서는 의미가 없습니다. 시스템을 변경할 의도가 없다면 엔트로피에 대해 말할 수 없습니다. 마찬가지로, 아직 존재하지 않는 시스템(즉, 다음 반복이 실제로 존재의 첫 번째 반복임)에는 엔트로피가 없습니다.

소프트웨어는 사용자의 관점에서 "버그"로 인식될 수 있지만 후속 반복 중에 소프트웨어 개발자와 관리자가 계획대로 목표를 달성한다면 시스템의 엔트로피가 실제로 매우 낮다고 결론을 내려야 합니다! 따라서 사용자의 경험은 소프트웨어 엔트로피에 대해 거의 말해주지 않습니다.

• 소프트웨어 개발자는 소프트웨어에 대한 유동적인 관점을 가지고 있습니다. 그들은 시스템이 변경되어야 하는 한에서만 시스템이 현재 기능하는 방식에 관심이 있고 적절한 전략을 고안하기 위해 시스템이 어떻게 작동하는지에 대한 세부 사항에 관심이 있습니다.

• 관리자는 정적이든 유동적이든 소프트웨어에 대해 가장 복잡한 관점을 갖고 있을 것입니다. 그들은 단기의 긴급성과 미래로 확장되는 사업 계획의 요구 사이의 균형을 맞춰야 합니다.

이 두 가지 역할을 모두 수행하는 사람들에게는 기대치가 있습니다. 소프트웨어 엔트로피는 이러한 기대가 망칠 때마다 나타납니다. 즉, 소프트웨어 개발자와 관리자는 위험을 평가하고 그에 대한 계획을 세우기 위해 최선을 다하지만 외부 혼란을 제외하고 그들의 기대가 실망스럽다면 그때서야 ​​소프트웨어 엔트로피에 대해 말할 수 있습니다. 범위에 포함되지 않은 구성 요소 상호 작용을 중단하고 프로덕션 서버가 설명할 수 없는 충돌을 일으키며 시기 적절하고 비용 효율적인 핫픽스를 보류하는 것은 보이지 않는 손입니다.

높은 수준의 엔트로피를 가진 많은 시스템은 특히 개발 팀의 하위 구성원이 있는 경우 특정 개인에 의존합니다. 이 사람은 자신의 "가치 있는" 입력 없이는 다른 사람들이 작업을 수행할 수 없다는 지식을 가지고 있습니다. 예외, 직감 및 팁의 조합으로 구성되어 있기 때문에 표준 UML 다이어그램이나 기술 사양에서 캡처할 수 없습니다. 이 지식은 논리적으로 일관된 프레임워크에 의존하지 않으므로 다른 사람에게 이전하는 것이 불가능하지는 않더라도 어렵습니다.

큰 결단력과 노력으로 그러한 조직이 스스로를 돌이켜 IT 부서를 안정시킬 수 있다고 가정해 봅시다. 소프트웨어 개발이 중단되었을 때 모든 진전이 고무적이기 때문에 상황이 개선된 것 같습니다. 그러나 현실은 엔트로피가 아직 낮았을 때 도달할 수 있었던 높은 목표에 비해 기대치도 낮고 성취도 재미없었다.

소프트웨어 엔트로피가 프로젝트를 압도하면 프로젝트가 중단됩니다.

더 이상 개발 반복이 있을 수 없습니다. 다행히도 이러한 상황은 즉시 발생하지 않습니다. 절벽 가장자리를 향한 느리지만 가파르게 행군하는 것은 모든 시스템이 겪는 일입니다. 첫 번째 버전이 아무리 잘 조직되고 효율적이더라도, 연속적인 개발 반복을 통해 엔트로피(따라서 일이 예기치 않게 잘못될 위험)가 이를 방지하기 위한 특정 조치를 취하지 않는 한 증가할 것입니다.

소프트웨어 엔트로피는 줄일 수 없습니다. 현실 세계의 엔트로피와 마찬가지로 증가하거나 동일하게 유지됩니다. 처음에는 그 효과가 미미합니다. 증상이 나타나기 시작하면 증상이 경미하여 가리거나 무시할 수 있습니다. 그러나 조직에서 소프트웨어 엔트로피가 프로젝트에서 지배적인 위험이 된 후에만 소프트웨어 엔트로피와 싸우려고 시도한다면 슬프게도 그 노력이 헛된 것임을 알게 될 것입니다. 따라서 소프트웨어 엔트로피에 대한 인식은 그 정도가 낮고 부작용이 최소화될 때 가장 유용합니다.

모든 조직이 제품의 엔트로피 증가를 제한하는 데 자원을 투자해야 한다는 것은 아닙니다. 오늘날 개발 중인 소프트웨어의 대부분(특히 소비자 지향 소프트웨어)은 예상 수명이 몇 년 정도로 비교적 짧습니다. 이 경우 이해 관계자는 소프트웨어 엔트로피의 영향을 고려할 필요가 없습니다. 전체 시스템이 폐기되기 전에 심각한 장애물이 되는 경우가 거의 없기 때문입니다. 그러나 소프트웨어 엔트로피의 영향을 고려해야 할 덜 분명한 이유가 있습니다.

인터넷 라우팅 인프라를 실행하거나 한 은행 계좌에서 다른 은행 계좌로 돈을 이체하는 소프트웨어를 고려하십시오. 주어진 시간에 이 소프트웨어의 하나 이상의 버전이 프로덕션에 있으며 이들의 집합적인 동작은 상당히 높은 정확도로 문서화될 수 있습니다.

시스템의 위험 허용 범위는 한 번의 개발 반복에서 다음 개발 반복까지 편안하게 허용할 수 있는 예상치 못한 동작의 유형과 양을 측정한 것입니다. 방금 언급한 시스템 유형의 경우 위험 허용 범위는 전화 통화를 라우팅하는 소프트웨어보다 훨씬 낮습니다. 이 소프트웨어는 많은 상용 웹사이트의 장바구니를 구동하는 소프트웨어보다 위험 허용 범위가 낮습니다.

위험 허용 범위와 소프트웨어 엔트로피는 다음 개발 반복 동안 시스템의 위험 허용 범위 내에 머물도록 소프트웨어 엔트로피가 최소이어야 한다는 점에서 관련이 있습니다.

소프트웨어 엔트로피의 근원

소프트웨어 엔트로피 는 지식 부족 에서 발생합니다. 그것은 우리의 공동 가정과 기존 시스템의 실제 행동 사이의 차이에서 비롯됩니다. 이 사실은 소프트웨어 엔트로피가 기존 시스템을 수정하는 맥락에서만 의미가 있는 이유를 설명합니다. 우리의 이해 부족이 실질적인 영향을 미칠 수 있는 유일한 시간입니다. 소프트웨어 엔트로피는 한 사람이 세부 사항을 이해할 수 없지만 개발 팀 전체에 분산되어 있는 시스템에서 가장 비옥한 기반을 찾습니다. 시간 역시 지식을 지우는 강력한 도구입니다.

코드는 일련의 논리적 주장의 표현입니다. 소프트웨어의 동작(따라서 해당 코드)이 표현하려는 논리와 일치하지 않는 경우 고유한 엔트로피에 대해 말할 수 있습니다. 이 상황은 세 가지 방식으로 발생할 수 있습니다. 논리가 잘 알려져 있고 표현과 다른 경우, 코드가 표현하려는 논리에 대해 여러 가지 이해가 있는 경우 또는 논리가 잘 알려지지 않은 경우.

• 첫 번째 상황 (논리학이 잘 알려져 있고 현재 표현과 다른 경우)은 가장 다루기 쉽지만 가장 덜 일반적입니다. 개발자와 사업 계획을 담당하는 사람의 두 참가자가 유지 관리하는 아주 작은 시스템만 이 범주에 속합니다.

• 논리가 잘 알려지지 않은 두 번째 상황은 드뭅니다. 모든 의도와 목적을 위해 개발 반복을 시작할 수도 없습니다. 어떤 시점에서 모든 이해 관계자가 동의할 수 있다면 첫 번째 상황에 직면할 가능성이 높습니다.

인간의 마음은 경험을 해석하여 개인의 틀에 맞추기 위해 효과적으로 필터링하고 수정합니다. 자유로운 아이디어 교환, 상호 존중, 명확한 기대를 기반으로 하는 효과적인 개발 습관이 없는 경우 팀 구성원이 있는 만큼 시스템이 현재 기능하는 방식에 대한 다양한 해석이 있을 수 있습니다. 현재 개발 반복에 대한 팀의 목표 자체가 논쟁의 여지가 있습니다.

많은 개발자가 자신에게 필요한 것과 시스템이 "구성되어야 하는" 방법에 대한 고유한 이해를 강화하여 이러한 상황에서 자신을 보호합니다. 반면에 관리자와 기타 이해 관계자는 자신의 삶을 더 쉽게 만들려는 잘못된 시도에서 무의식적으로 다른 팀 구성원의 가정을 변경하려고 할 수 있습니다.

우리는 이제 가장 일반적인 소프트웨어 엔트로피 소스에 도달했습니다 . 시스템이 표현하려는 논리에 대한 여러 가지 불완전한 해석이 있습니다. 이 논리의 단 하나의 표현이 있기 때문에 상황은 정의상 문제가 있습니다.

이러한 지식 부족은 어떻게 발생합니까? 무능은 한 가지 방법입니다. 그리고 우리가 이미 보았듯이 다음 개발 반복의 목표에 대한 합의 부족은 또 다른 문제입니다. 그러나 고려해야 할 다른 요소가 있습니다. 조직은 개발 방법론을 사용한다고 주장하지만 우연히 현장에서 일부 또는 전체 측면을 포기할 수 있습니다. 그런 다음 소프트웨어 개발자는 모호한 할당을 완료해야 하며, 종종 해석의 여지가 있습니다. 개발 방법론에 대한 변경을 구현하는 조직은 이러한 현상에 특히 취약하지만 유일한 것은 아닙니다. 경영진이 알지 못하거나 해결할 수 없는 개인적인 갈등은 기대와 결과 사이의 위험한 차이로 이어질 수도 있습니다.

제품에 대한 기술 지식을 잃는 더 중요한 두 번째 방법이 있습니다. 바로 이전입니다. 기술 지식을 종이에 기록하는 것은 가장 능숙한 작가에게도 어려운 일입니다. 그 이유는 무엇 을 필사하는가 만큼이나 중요 하기 때문입니다. 적절한 규율이 ​​없으면 기술 작성자가 너무 많은 정보를 기록할 수 있습니다. 대안으로, 그들은 핵심 사항을 생략하게 만드는 가정을 할 수 있습니다. 기술 문서가 생성된 후 기술 문서를 세심하게 최신 상태로 유지해야 합니다. 이는 문서를 작성하는 즉시 추적하지 못하는 많은 조직에게 어려운 제안입니다. 이러한 어려움 때문에 기술 지식은 문서 단독으로 전달되는 경우는 거의 없지만 쌍으로 또는 다른 형태의 긴밀한 인간 대 인간 상호 작용 형태로도 전달됩니다.

소프트웨어 엔트로피는 적극적인 참가자가 개발 팀을 떠날 때마다 도약합니다. 그들은 귀중한 노하우를 가지고 있습니다. 그 노하우를 복제하는 것은 불가능하며, 이를 근사화하려면 상당한 노력이 필요합니다. 그러나 충분한 관심과 자원이 있으면 시스템의 엔트로피 증가를 최소화할 수 있는 충분한 지식이 보존될 수 있습니다.

엔트로피에 대한 다른 소스가 있지만 이들은 상대적으로 미미합니다. 예를 들어 소프트웨어 썩음은 시스템이 환경 변경으로 인해 예기치 않게 영향을 받는 프로세스입니다. 의존하는 타사 소프트웨어(예: 라이브러리)를 생각할 수 있지만 일반적으로 시스템이 기반으로 하는 가정의 변경으로 인해 소프트웨어 부패의 더 교활한 다른 원인이 있습니다. 예를 들어, 시스템이 메모리 가용성에 대한 특정 가정으로 설계된 경우 사용 가능한 메모리가 줄어들면 예기치 않은 순간에 오작동이 시작될 수 있습니다.

엔트로피 계산 방법: 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는 음수 값을 가질 수 있습니다. 그러나 실제로는 이러한 상황이 발생하지 않습니다. 우리는 일반적으로 실수로 문제를 해결하지 않습니다. 나 에 대한 부정적인 가치는 위안이 되는 신호가 아닙니다. 그들은 엔트로피를 계산하는 수단에 결함이 있음을 암시합니다. 물론 소프트웨어 엔트로피의 증가는 아래에 설명된 대로 특정 조치를 취함으로써 줄일 수 있습니다. 그러나 그러한 경우에 우리 는 항상 우리의 기대를 디자인에 반영하기 때문에 부정적인 값을 가정해서는 안됩니다.

C는 주관적인 값입니다. 이는 개발 반복 참가자의 마음에 존재하며 참가자를 폴링하고 결과를 평균화하여 추론할 수 있습니다. 질문은 긍정적인 방식으로 해야 합니다. 예: "가장 가능성이 10인 0에서 10까지의 척도에서 팀이 이번 개발 반복에서 모든 목표를 달성할 가능성을 어떻게 추정하시겠습니까?"

이 질문은 부분 집합이 아니라 전체 팀의 목표에 대해 제기되고 있습니다. 10의 응답은 C의 경우 0의 값을 나타내는 반면 7의 응답은 .3의 값을 나타냅니다. 규모가 큰 팀에서는 개인이 프로젝트에 참여한 기간과 실제로 프로젝트에 소요된 시간과 같은 관련 요소에 따라 각 응답에 가중치를 둘 수 있습니다. 그러나 능력은 응답에 가중치를 부여하는 요인이 되어서는 안 됩니다. 머지 않아 팀의 하급 구성원도 목표를 달성하는 데 얼마나 효과적인지 알게 될 것입니다. 충분히 큰 팀은 나머지를 평균화하기 전에 보고된 가장 높은 값과 가장 낮은 값을 버리기를 원할 수 있습니다.

전문가들에게 팀이 실패할 가능성이 얼마나 되는지 묻는 것은 민감하고 도발적인 제안입니다. 그러나 이것은 엔트로피를 정량화하려는 조직이 물어야 할 질문입니다. 정직한 답변을 보장하기 위해 참가자는 익명으로 C에 대한 평가를 제공해야 하며, 비록 그들이 매우 높은 값을 보고하더라도 영향에 대한 두려움 없이 제공해야 합니다.

S는 I 와 동일한 "작업 단위"에 값을 할당해야 하므로 개발 방법론에 크게 의존합니다. 애자일 방법론의 측면을 사용하는 팀의 경우 스토리는 S와 I 모두에게 가장 명백한 "작업 단위"로 보입니다. 이 경우 개발 반복의 범위는 정기적으로 예정된 각 릴리스가 마이너 또는 메이저로 프로덕션으로 확장됩니다. 나는 출시까지의 각 스프린트 동안 성공적으로 완료되지 않은 스토리 수와 출시 이후에 나타나는 예상치 못한 문제의 결과로 향후 스프린트에 포함시키기 위해 생성된 스토리 수의 합계로 수량화되어야 ​​합니다.

핫픽스나 기타 예정되지 않은 프로덕션 릴리스를 개발 반복의 범위를 정의하는 것으로 간주하지 않으며 I 에서 관련 스토리를 빼서도 안 됩니다.

이 접근 방식의 어려움은 버그가 이후에 스토리로 분류되기 전에 발견 및 분석 기간이 발생해야 한다는 것입니다. 따라서 I의 실제 값은 지연 후에만 정의할 수 있습니다. 또한 C에 대한 폴링은 각 스프린트가 시작될 때 자연스럽게 발생합니다. 따라서 얻은 결과는 전체 릴리스의 범위에 대해 다시 한 번 평균을 내야 합니다. 이러한 어려움에도 불구하고 Agile 방법론의 측면을 사용하는 모든 팀은 스토리가 S(및 따라서 I )를 수량화하는 가장 정확한 단위라는 것을 알게 될 것입니다.

오늘날 사용 중인 다른 개발 방법론이 있습니다. 어떤 방법을 사용하든 소프트웨어 엔트로피를 측정하는 원칙은 동일하게 유지됩니다. 소프트웨어 엔트로피는 프로덕션 릴리스 사이에서 측정되어야 하고, S와 I는 동일한 "작업 단위"에서 측정되어야 하며, C의 추정치는 직접 참가자로부터 가져와야 합니다. 위협적이지 않고 가급적이면 익명으로.

E의 성장 감소

시스템에 대한 지식은 한 번 잃으면 다시 얻을 수 없습니다. 이러한 이유로 소프트웨어 엔트로피를 줄일 수 없습니다. 우리가 할 수 있는 것은 성장을 억제하는 것뿐입니다.

엔트로피의 증가는 소프트웨어 개발 중에 적절한 조치를 취함으로써 제한될 수 있습니다. 애자일 개발의 쌍 프로그래밍 측면은 이와 관련하여 특히 유용합니다. 코드가 작성될 때 둘 이상의 개발자가 관련되기 때문에 필수 세부 정보에 대한 지식이 배포되고 팀 구성원을 떠나는 영향이 완화됩니다.

또 다른 유용한 방법은 특히 폭포수 방법론을 사용하는 조직 내에서 잘 구조화되고 쉽게 사용할 수 있는 문서를 생성하는 것입니다. 그러한 문서는 모든 사람이 이해하는 엄격하고 잘 정의된 원칙에 의해 뒷받침되어야 합니다. 문서화를 주요 커뮤니케이션 수단으로 사용하고 기술 지식을 보호하는 조직은 이러한 접근 방식에 적합합니다. 내부적으로 작성된 문서를 작성하고 사용하는 방법에 대한 지침이나 교육이 없을 때만(RAD 또는 Agile 방법론을 사용하는 젊은 조직의 경우처럼) 그 가치가 의심스러워집니다.

시스템에서 엔트로피 증가를 줄이는 두 가지 방법이 있습니다. I 를 줄이기 위한 변경을 실행하거나 C를 줄이기 위한 변경을 실행합니다.

첫 번째는 리팩토링을 포함합니다. I를 줄이기 위한 조치는 본질적으로 기술적인 경향이 있으며 독자에게 이미 익숙할 것입니다. 개발 반복이 발생해야 합니다. 엔트로피의 증가를 줄이기 위한 이 반복 부분은 시간과 리소스를 소비하는 동안 실질적인 비즈니스 이점을 제공하지 않습니다 . 이 사실은 종종 엔트로피의 성장을 줄이는 것을 조직 내에서 어려운 판매로 만듭니다.

효과가 장기적이기 때문에 C 값을 줄이는 것이 더 강력한 전략입니다. 또한 C는 I 대 S의 비율 증가에 대한 중요한 확인 역할을 합니다. C를 줄이기 위한 조치는 인간의 행동과 사고에 초점을 맞추는 경향이 있습니다. 이러한 작업은 자체 개발 반복이 필요하지 않을 수 있지만 참가자가 새로운 절차를 수락하고 적응함에 따라 후속 반복이 느려집니다. 개선해야 할 사항에 대해 합의하는 단순해 보이는 행동은 프로젝트 참가자와 이해 관계자의 이질적인 목표가 갑자기 드러나면서 그 자체로 위험이 도사리고 있는 길입니다.

마무리

소프트웨어 엔트로피는 기존 소프트웨어를 변경하면 예기치 않은 문제, 충족되지 않은 목표 또는 둘 모두가 발생할 위험이 있습니다.

소프트웨어가 처음 생성될 때는 무시할 수 있지만 소프트웨어 엔트로피는 개발이 반복될 때마다 커집니다. 확인하지 않고 계속 진행하면 소프트웨어 엔트로피로 인해 결국 추가 개발이 중단됩니다.

그러나 모든 프로젝트가 소프트웨어 엔트로피의 영향을 고려해야 하는 것은 아닙니다. 엔트로피가 눈에 띄고 해로운 영향을 미치기 전에 많은 시스템이 생산에서 중단될 것입니다. 엔트로피가 신뢰할 수 있는 위험을 제기할 만큼 수명이 긴 사람들에게 엔트로피에 대한 인식을 높이고 그 범위를 측정하는 것은 여전히 ​​낮지만 개발이 조기에 중단되지 않도록 하는 수단을 제공합니다.

시스템이 소프트웨어 엔트로피의 영향으로 완전히 압도되면 더 이상 변경할 수 없으며 개발은 본질적으로 종료됩니다.