Entropia software explicată: cauze, efecte și remedii

Acest articol se adresează dezvoltatorului de software sau managerului de proiect care este curios de ce este entropia software, efectele practice asupra muncii lor și factorii care stau la baza care contribuie la creșterea acestuia.

Scopul principal este de a crea o conștientizare a entropiei software , deoarece este un factor în toate formele de dezvoltare software. Mai mult, explorăm un mijloc prin care entropiei software-ului i se poate atribui o valoare concretă. Numai cuantificând entropia software-ului și observând creșterea acestuia de-a lungul lansărilor succesive, putem înțelege cu adevărat riscul pe care îl prezintă pentru obiectivele noastre actuale și planurile de viitor.

Ce este Entropia software?

Entropia software își câștigă numele de la caracteristica principală a entropiei în lumea reală: este o măsură a haosului care fie rămâne la fel, fie crește în timp . Altfel spus, este o măsură a instabilității inerente încorporate într-un sistem software în ceea ce privește modificarea acestuia.

Din păcate, entropiei software-ului i se acordă rareori importanța pe care o merită.

Nu i se ia în considerare atunci când trageți pe cineva dintr-o echipă de dezvoltare, începeți prematur un ciclu de dezvoltare sau implementați „remedieri rapide” – momente în care, de fapt, este cel mai probabil să crească.

Dezvoltarea software este o artă și o meserie ale căror elemente de bază sunt prost definite. În timp ce constructorii lucrează cu ciment și cuie, dezvoltatorul de software lucrează cu afirmații logice și un set de ipoteze. Acestea nu pot fi ținute în mână și examinate și nici nu pot fi comandate la optul de inch. Deși observatorul ocazional ar putea fi tentat să compare dezvoltarea de software cu construcția, dincolo de câteva asemănări superficiale este contraproductiv să facă acest lucru.

În ciuda acestor dificultăți, putem totuși să stabilim liniile directoare care ne vor permite să înțelegem sursele entropiei software, să măsuram gradul de risc pe care îl prezintă pentru obiectivele noastre și (dacă este necesar) ce măsuri pot fi luate pentru a limita creșterea acesteia.

Definiția propusă a entropiei software este următoarea:

unde I este derivat din numărul de probleme neașteptate introduse în timpul ultimei iterații de dezvoltare, C este probabilitatea percepută ca implementarea modificărilor în sistem să ducă acum la un nou I > 0, iar S este domeniul de aplicare al următoarei iterații de dezvoltare. În general, valorile lui E sub 0,1 sunt considerate bune. Un E de 0,5 este considerat ridicat, iar valorile de peste 1,0 sunt copleșitoare.

Conceptul de iterație de dezvoltare este parte integrantă a înțelegerii noastre a entropiei software. Acestea sunt cicluri de activitate care duc de la un comportament al sistemului la altul. Obiectivele pe care ni le-am stabilit în timpul iterației software se numesc domeniul său de aplicare . În dezvoltarea de software, astfel de cicluri implică modificarea sau extinderea codului de bază al software-ului.

Toate modificările aduse codului apar într-o iterație de dezvoltare, chiar dacă cei care le efectuează nu le gândesc în acest fel. Adică, organizațiile mai mici care se mândresc cu construirea sistemelor lor folosind o metodologie „rapidă și murdară” – cu o adunare redusă sau deloc de cerințe sau analize – încă folosesc iterații de dezvoltare pentru a-și atinge obiectivele. Pur și simplu nu le planifică. În mod similar, chiar dacă comportamentul unui sistem modificat diverge într-un fel de intențiile noastre, acesta a fost totuși realizat prin intermediul unei iterații de dezvoltare.

De fapt, riscul ca acest lucru să se întâmple este exact ceea ce conștientizarea noastră despre entropia software intenționează să explice și dorința noastră de a o măsura intenționează să limiteze. În termeni practici, atunci putem defini entropia software după cum urmează.

Orice sistem dat are un set finit de probleme cunoscute, deschise I ₀ . La sfârșitul următoarei iterații de dezvoltare, va exista un set finit de probleme cunoscute, deschise I ₁ . Entropia inerentă a sistemului specifică cât de mult este probabil să difere așteptările noastre de I ₁ față de valoarea sa reală și cât de mult este probabil să crească diferența în iterațiile ulterioare.

Efectele entropiei software

Experiența noastră practică a efectelor entropiei software depinde de modul în care interacționăm cu sistemul în cauză.

Utilizatorii au o vedere statică a software-ului; sunt preocupați de modul în care se comportă acum și nu le pasă de elementele interne ale unui sistem. Prin efectuarea unei acțiuni predefinite, utilizatorii presupun că software-ul va răspunde cu un comportament predefinit corespunzător. Cu toate acestea, utilizatorii sunt cei mai puțin pregătiți să deducă nivelul de entropie din software-ul pe care îl folosesc.

Entropia software este legată de noțiunea de schimbare și nu are sens într-un sistem static. Dacă nu există intenția de a modifica sistemul, nu putem vorbi de entropia lui. De asemenea, un sistem care nu există încă (adică următoarea iterație este de fapt prima din existența sa) nu are entropie.

Software-ul poate fi perceput ca „buggy” din punctul de vedere al unui utilizator, dar dacă în timpul iterațiilor ulterioare dezvoltatorii și managerii de software își îndeplinesc obiectivele așa cum au fost planificate, trebuie să concluzionăm că entropia în sistem este de fapt destul de scăzută! Prin urmare, experiența utilizatorilor ne spune foarte puțin, dacă este ceva, despre entropia software:

• Dezvoltatorii de software au o viziune fluidă asupra software-ului. Aceștia sunt preocupați de modul în care un sistem funcționează în prezent doar în măsura în care trebuie schimbat și sunt preocupați de detaliile modului în care funcționează pentru a concepe o strategie adecvată.

• Managerii au poate cea mai complicată viziune asupra software-ului, atât statică, cât și fluidă. Ei trebuie să echilibreze exigențele pe termen scurt cu cerințele unui plan de afaceri care se extinde mai mult în viitor.

Oamenii din ambele roluri au așteptări. Entropia software se manifestă ori de câte ori aceste așteptări sunt stricate. Adică, dezvoltatorii și managerii de software fac tot posibilul să evalueze riscurile și să le planifice, dar – excluzând întreruperile externe – dacă așteptările lor sunt totuși dezamăgite, abia atunci putem vorbi de entropia software. Mâna invizibilă este cea care întrerupe interacțiunile componentelor care nu erau în domeniul de aplicare, provoacă blocarea inexplicabilă a serverelor de producție și reține o remediere rapidă în timp util și rentabilă.

Multe sisteme cu niveluri ridicate de entropie se bazează pe indivizi specifici, mai ales dacă există membri juniori ai echipei de dezvoltare. Această persoană posedă cunoștințe astfel încât ceilalți nu își pot îndeplini sarcinile fără contribuția sa „valoroasă”. Nu poate fi surprins în diagrame UML standard sau specificații tehnice, deoarece constă dintr-un amalgam de excepții, bănuieli și sfaturi. Această cunoaștere nu depinde de un cadru logic consistent și, prin urmare, este dificil – dacă nu imposibil – să fie transferată oricui altcineva.

Să presupunem că, cu multă hotărâre și efort, o astfel de organizație este capabilă să se întoarcă și să-și stabilizeze departamentul IT. Situația pare să se fi îmbunătățit deoarece, atunci când dezvoltarea software-ului s-a oprit, orice progres este încurajator. Cu toate acestea, în realitate, așteptările îndeplinite sunt scăzute, iar realizările neinteresante în comparație cu obiectivele înalte care erau la îndemână în timp ce entropia era încă scăzută.

Când entropia software copleșește un proiect, proiectul se blochează.

Nu mai pot exista iterații de dezvoltare. Din fericire, această situație nu apare instantaneu. Marșul lent, dar abrupt către marginea unei stânci este ceva prin care trece fiecare sistem. Indiferent cât de bine organizată și eficientă ar fi prima versiune, peste iterații succesive de dezvoltare entropia sa - și, prin urmare, riscul ca lucrurile să meargă greșit în mod neașteptat - va crește dacă nu se iau măsuri specifice pentru a o preveni.

Entropia software nu poate fi redusă. La fel ca entropia în lumea reală, ea crește sau rămâne la fel. La început, efectele sale sunt neglijabile. Când încep să se manifeste, simptomele sunt ușoare și pot fi mascate sau ignorate. Dar dacă o organizație încearcă să combată entropia software doar odată ce a devenit riscul dominant într-un proiect, va constata, din păcate, că eforturile sale sunt în zadar. Prin urmare, cunoașterea entropiei software este cea mai utilă atunci când amploarea acesteia este scăzută și efectele adverse minime.

Nu înseamnă că fiecare organizație ar trebui să aloce resurse limitării creșterii entropiei în produsele sale. O mare parte din software-ul dezvoltat astăzi, în special software-ul orientat spre consumator, are o durată de viață estimată relativ scurtă, poate câțiva ani. În acest caz, părțile interesate nu trebuie să ia în considerare efectele entropiei software, deoarece rareori va deveni un obstacol serios înainte ca întregul sistem să fie aruncat. Există, totuși, motive mai puțin evidente pentru a lua în considerare efectele entropiei software.

Luați în considerare software-ul care rulează infrastructura de rutare a internetului sau transferă bani dintr-un cont bancar în altul. În orice moment, există una sau mai multe versiuni ale acestui software în producție, iar comportamentele lor colective pot fi documentate cu o acuratețe destul de ridicată.

Toleranța la risc a unui sistem este o măsură a cât de mult și ce tip de comportament neașteptat putem permite confortabil de la o iterație de dezvoltare la alta. Pentru tipurile de sisteme tocmai menționate, toleranța la risc este mult mai mică decât, de exemplu, software-ul care direcționează apelurile telefonice. Acest software, la rândul său, are o toleranță la risc mai mică decât software-ul care conduce coșul de cumpărături al multor site-uri web comerciale.

Toleranța la risc și entropia software sunt legate prin aceea că entropia software trebuie să fie minimă pentru a fi siguri că vom rămâne în toleranța la risc a unui sistem în timpul următoarei iterații de dezvoltare.

Surse de Entropie Software

Entropia software-ului apare din lipsa de cunoștințe . Rezultă din divergența dintre ipotezele noastre comune și comportamentul real al unui sistem existent. Acest fapt explică de ce entropia software are sens doar în contextul modificării unui sistem existent; este singura dată când lipsa noastră de înțelegere va avea vreun efect practic. Entropia software găsește cel mai fertil teren într-un sistem ale cărui detalii nu pot fi înțelese de o singură persoană, ci sunt răspândite în jurul unei echipe de dezvoltare. Timpul, de asemenea, este o puternică ștergere a cunoștințelor.

Codul este expresia unei serii de afirmații logice. Atunci când comportamentul software-ului (și, prin urmare, codul său) nu corespunde logicii pe care intenționează să o exprime, putem vorbi de entropia sa inerentă. Această situație poate apărea în trei moduri: logica este bine cunoscută și diverge de la expresia ei, există mai multe înțelegeri ale logicii pe care codul este destinat să o exprime sau logica nu este bine cunoscută.

• Prima situație – logica este bine cunoscută și se abate de la expresia actuală – este cea mai ușor de abordat, dar și cea mai puțin comună. Doar sistemele foarte mici întreținute de probabil doi participanți, un dezvoltator și cineva responsabil de planul de afaceri, vor intra în această categorie.

• A doua situație — logica nu este bine cunoscută — este rară. Pentru toate scopurile, iterația de dezvoltare nici măcar nu poate începe. Dacă la un moment dat toate părțile interesate pot fi de acord, atunci este probabil că ei se vor confrunta cu prima situație.

Mintea umană își interpretează experiențele, filtrăndu-le și modificându-le în mod eficient în încercarea de a le încadra într-un cadru personal. În absența unor obiceiuri eficiente de dezvoltare – bazate pe un schimb liber de idei, respect reciproc și așteptări clare – pot exista la fel de multe interpretări ale modului în care funcționează un sistem în prezent, câte membri ai echipei. Obiectivele echipei pentru iterația actuală de dezvoltare pot fi ele însele în discuție.

Mulți dezvoltatori se protejează de această situație, consolidându-și propriile înțelegeri unice asupra a ceea ce li se cere și a modului în care sistemul „ar trebui” să fie organizat. Managerii și alte părți interesate, pe de altă parte, ar putea încerca fără să vrea să schimbe ipotezele altor membri ai echipei într-o încercare greșită de a-și face viața mai ușoară.

Am ajuns acum la cea mai comună sursă de entropie software: există multiple interpretări incomplete ale logicii pe care sistemul este destinat să o exprime. Deoarece există o singură manifestare a acestei logici, situația este prin definiție problematică.

Cum apare această lipsă de cunoștințe? Incompetența este o singură cale. Și așa cum am văzut deja, lipsa unui acord cu privire la obiectivele următoarei iterații de dezvoltare este alta. Dar mai sunt și alți factori de luat în considerare. O organizație poate pretinde că folosește o metodologie de dezvoltare, dar apoi abandonează întâmplător unele sau toate aspectele sale pe teren. Dezvoltatorii de software au apoi sarcina de a îndeplini sarcini vagi, adesea deschise interpretării. Organizațiile care implementează modificări în metodologia lor de dezvoltare sunt deosebit de vulnerabile la acest fenomen, deși nu sunt deloc singurele. Conflictele personale de care conducerea nu este conștientă sau altfel nu le poate rezolva pot duce, de asemenea, la o divergență periculoasă între așteptări și rezultate.

Există un al doilea mod, mai important, prin care pierdem cunoștințele tehnice despre un produs: prin transfer. Captarea cunoștințelor tehnice pe hârtie este o provocare chiar și pentru cei mai pricepuți scriitori. Motivul este că ce să transcrie este la fel de important ca și cum . Fără disciplina adecvată, un scriitor tehnic poate înregistra prea multe informații. Alternativ, ei pot face presupuneri care îi fac să omite puncte esențiale. După ce este produsă, documentația tehnică trebuie păstrată cu meticulozitate la zi, o propunere dificilă pentru multe organizații care pierd evidența documentelor aproape imediat ce sunt scrise. Din cauza acestor dificultăți, cunoștințele tehnice sunt rareori transferate doar în documente, ci și în perechi sau alte forme de interacțiune apropiată, de la om la om.

Entropia software face salturi și limite ori de câte ori un participant activ părăsește o echipă de dezvoltare. Ei iau cu ei o bucată valoroasă de know-how. Replicarea acestui know-how este imposibilă și aproximarea acestuia necesită un efort considerabil. Cu suficientă atenție și resurse, totuși, se pot păstra suficiente cunoștințe pentru ca creșterea entropiei sistemului să poată fi minimizată.

Există și alte surse de entropie, dar acestea sunt relativ minore. De exemplu, putregaiul software este procesul prin care un sistem este afectat în mod neașteptat de schimbările aduse mediului său. Ne putem gândi la software terță parte pe care se bazează (cum ar fi bibliotecile), dar există și alte cauze mai insidioase ale putregaiului software, care de obicei rezultă din modificările ipotezelor pe care sa bazat sistemul. De exemplu, dacă un sistem a fost proiectat cu anumite ipoteze despre disponibilitatea memoriei, acesta poate începe să funcționeze defectuos în momente neașteptate dacă memoria disponibilă este redusă.

Cum se calculează entropia: Atribuirea valorilor lui C, S și I

I este numărul de probleme de comportament nerezolvate dintr-un sistem software, inclusiv absența caracteristicilor promise. Aceasta este o cantitate cunoscută care este adesea urmărită într-un sistem precum JIRA. Valoarea lui I este derivată direct din aceasta. I este numărul de „unități de lucru” care au fost abandonate sau lăsate incomplete în timpul ultimei iterații de dezvoltare, în plus față de numărul de unități de lucru care rezultă din probleme de comportament nou introduse și neașteptate. Deoarece I este numărat ca un număr de unități de lucru, îl putem raporta la valoarea lui S, care este domeniul de aplicare al următoarei iterații de dezvoltare în aceleași unități de lucru. Ceea ce cuprinde exact o „unitate de lucru” depinde de metodologia de dezvoltare.

C este probabilitatea percepută ca, atunci când unitățile de lucru din domeniu au fost implementate, numărul de probleme deschise efective I1 în următoarea iterație să fie mai mare decât estimarea sa acum. Această valoare locuiește în domeniul 0 <= C <= 1.

S-ar putea susține că probabilitatea C este exact ceea ce pretinde să măsoare entropia software. Cu toate acestea, există diferențe fundamentale între această valoare și măsura noastră a entropiei software. Probabilitatea percepută ca ceva să meargă prost este exact aceea: nu este o valoare reală. Cu toate acestea, este util prin faptul că sentimentele persoanelor care participă la un proiect sunt o sursă valoroasă de informații despre cât de stabil este acesta.

Domeniul S ia în considerare amploarea modificărilor propuse și trebuie exprimat în aceleași unități ca și I. O valoare mai mare a lui S scade entropia deoarece creștem domeniul de aplicare al modificărilor propuse. Deși acest lucru poate suna contraintuitiv, trebuie să ținem cont de faptul că entropia este o măsură a modului în care dezvoltarea sistemului poate să nu satisfacă așteptările noastre. Nu este suficient să spunem că entropia este o măsură a șansei de a introduce probleme. În mod firesc, încercăm să anticipăm riscurile și să le luăm în considerare în planificarea noastră (și, prin urmare, în estimarea noastră pentru I1, care poate crește peste ₀ ). În mod clar, cu cât suntem mai încrezători în ceea ce privește asumarea unui domeniu mare de schimbare, cu atât se poate spune că este mai puțină entropie în sistem - cu excepția cazului în care cei care planifică schimbările și/sau le efectuează sunt incompetenți. Această posibilitate, însă, se reflectă probabil în valoarea actuală a lui I .

Rețineți că nu trebuie să încercăm să specificăm mărimea diferenței dintre valoarea reală a lui I ₁ și valoarea sa așteptată. Dacă presupunem că planurile noastre sunt corecte atunci când le facem, nu este de asemenea rezonabil să presupunem că putem prezice gradul în care rezultatul nu va îndeplini așteptările noastre; putem specifica doar o șansă percepută C că nu va fi. Cu toate acestea, gradul în care valoarea reală I ₁ diferă de valoarea sa așteptată este o intrare importantă în calculul entropiei în următoarea iterație sub forma valorii derivate I .

Teoretic, este posibil ca eu să aibă o valoare negativă. În practică însă, această situație nu va apărea niciodată; de obicei nu rezolvăm problemele accidental. Valorile negative pentru I nu sunt un semn reconfortant. Ele sugerează că mijloacele prin care se calculează entropia sunt greșite. Creșterea entropiei software poate fi, desigur, redusă prin luarea de măsuri specifice, așa cum este descris mai jos. Cu toate acestea, în astfel de cazuri, nu ar trebui să-mi asum valori negative, deoarece întotdeauna încorporăm așteptările noastre în design-ul nostru.

C este o valoare subiectivă. Există în mintea participanților la o iterație de dezvoltare și poate fi dedus prin sondajul acestora și prin mediarea rezultatelor. Întrebarea ar trebui pusă într-un mod pozitiv. De exemplu: „Pe o scară de la 0 la 10 cu 10 cel mai probabil, cum ați estima șansele echipei de a-și atinge toate obiectivele în această iterație de dezvoltare?”

Rețineți că întrebarea este pusă cu privire la obiectivele echipei ca întreg, nu un subset. Un răspuns de 10 ar indica o valoare de 0 pentru C, în timp ce un răspuns de 7 ar indica o valoare de .3. În echipele mai mari, fiecare răspuns poate fi ponderat în funcție de factori relevanți, cum ar fi cât de mult timp a fost implicat o persoană în proiect și cât de mult timp este petrecut efectiv pentru acesta. Cu toate acestea, competența nu ar trebui să fie un factor în ponderarea răspunsurilor. În curând, chiar și un membru junior al echipei va avea o idee cât de eficient este în atingerea obiectivelor sale. Echipele suficient de mari ar putea dori să renunțe la cele mai mari și cele mai mici valori raportate înainte de a face media celor rămase.

A întreba profesioniștii cât de probabil este echipa lor să eșueze este o propunere sensibilă și provocatoare. Cu toate acestea, aceasta este exact întrebarea pe care trebuie să o pună orice organizație care dorește să cuantifice entropia. Pentru a asigura răspunsuri sincere, participanții ar trebui să-și dea estimarea despre C în mod anonim și fără teamă de repercusiuni, chiar dacă raportează o valoare abisal de mare.

S trebuie să i se atribuie o valoare în aceleași „unități de lucru” ca și I și, prin urmare, este foarte dependent de metodologia de dezvoltare. Pentru echipele care folosesc aspecte ale unei metodologii Agile, poveștile par cea mai evidentă „unitate de lucru” atât pentru S, cât și pentru I. În acest caz, amploarea unei iterații de dezvoltare se întinde pe fiecare lansare programată în mod regulat în producție, fie minoră sau majoră. Ar trebui să fiu cuantificat ca suma numărului de povești care nu au fost finalizate cu succes în timpul fiecărui sprint până la lansare și numărul de povești generate pentru a fi incluse în sprinturile viitoare ca urmare a unor probleme neașteptate care se manifestă după lansare.

Rețineți că nu considerăm remedierile rapide sau alte lansări neprogramate pentru producție ca definind amploarea unei iterații de dezvoltare și nici nu ar trebui să scădem poveștile asociate din I .

Dificultatea acestei abordări este că trebuie să aibă loc o perioadă de descoperire și analiză înainte ca erorile să poată fi ulterior împărțite în povești. Prin urmare, adevărata valoare a lui I poate fi definită numai după o întârziere. În plus, sondajul pentru C are loc în mod natural la începutul fiecărui sprint. Rezultatele obținute trebuie, prin urmare, să fie din nou mediate pe durata întregii ediții. În ciuda acestor dificultăți, orice echipă care utilizează aspecte ale unei metodologii Agile este probabil să constate că poveștile sunt cea mai precisă unitate pentru cuantificarea S (și, prin urmare, I ).

Există și alte metodologii de dezvoltare utilizate astăzi. Indiferent de metodologia folosită, principiile de măsurare a entropiei software rămân aceleași: entropia software-ului ar trebui măsurată între lansări până la producție, S și I ar trebui măsurate în aceleași „unități de lucru”, iar estimările lui C ar trebui luate de la participanții direcți în într-o manieră neamenințătoare și de preferință anonimă.

Reducerea creșterii E

Odată ce cunoștințele despre un sistem sunt pierdute, nu pot fi recâștigate niciodată. Din acest motiv, entropia software nu poate fi redusă. Tot ce putem spera să facem este să-i reținem creșterea.

Creșterea entropiei poate fi limitată prin adoptarea de măsuri adecvate în timpul dezvoltării software. Aspectul de programare în pereche al dezvoltării Agile este deosebit de util în acest sens. Deoarece sunt implicați mai mulți dezvoltatori la momentul scrierii codului, cunoștințele esențiale sunt distribuite și efectele membrilor echipei care pleacă sunt atenuate.

O altă practică utilă este producerea de documentație bine structurată și ușor de consumat, în special în cadrul organizațiilor care folosesc o metodologie în cascadă. O astfel de documentare trebuie să fie susținută de principii stricte și bine definite, înțelese de toată lumea. Organizațiile care se bazează pe documentație ca mijloc principal de comunicare și de protejare a cunoștințelor tehnice sunt potrivite pentru această abordare. Valoarea lor devine suspectă doar atunci când nu există linii directoare sau instruire cu privire la cum să scrieți și să consumați documente scrise intern - așa cum este adesea cazul în organizațiile mai tinere care folosesc metodologii RAD sau Agile.

Există două moduri de a reduce creșterea entropiei într-un sistem: Executați modificări destinate să reducă I sau executați modificări destinate să reducă C.

Prima implică refactorizarea. Acțiunile menite să reducă tind să fie de natură tehnică și probabil că sunt deja familiare cititorului. Trebuie să apară o iterație de dezvoltare. Partea din această iterație care are scopul de a reduce creșterea entropiei nu va oferi niciun beneficiu tangibil de afaceri, în timp ce va consuma timp și resurse. Acest fapt face adesea ca reducerea creșterii entropiei să fie o vânzare grea în cadrul oricărei organizații.

Reducerea valorii lui C este o strategie mai puternică, deoarece efectul este pe termen mai lung. În plus, C acționează ca un control important asupra creșterii raportului dintre I și S. Acțiunile de reducere a C tind să se concentreze asupra comportamentului și gândirii umane. Deși este posibil ca aceste acțiuni să nu necesite o iterație de dezvoltare în sine, ele vor încetini iterațiile ulterioare pe măsură ce participanții acceptă și se adaptează la noile proceduri. Actul aparent simplu de a conveni asupra îmbunătățirilor care ar trebui făcute este o cale plină de pericole proprii, pe măsură ce obiectivele disparate ale participanților la proiect și ale părților interesate ies brusc la lumină.

Încheierea

Entropia software este riscul ca schimbarea software-ului existent să aibă ca rezultat probleme neașteptate, obiective nerealizate sau ambele.

Deși neglijabilă atunci când software-ul este creat pentru prima dată, entropia software crește cu fiecare iterație de dezvoltare. Dacă se permite să continue necontrolat, entropia software-ului va opri în cele din urmă dezvoltarea ulterioară.

Cu toate acestea, nu orice proiect ar trebui să ia în considerare efectele entropiei software. Multe sisteme vor fi scoase din producție înainte ca entropia să poată exercita efecte vizibile și dăunătoare. Pentru cei a căror durată de viață este suficient de lungă încât entropia prezintă un risc credibil, conștientizarea acesteia și măsurarea extinderii acesteia, deși încă scăzută, oferă un mijloc de a se asigura că dezvoltarea nu este întreruptă prematur.

Odată ce un sistem a fost complet copleșit de efectele entropiei software, nu mai pot fi făcute modificări, iar dezvoltarea sa încheiat în esență.