Tämä artikkeli on suunnattu ohjelmistokehittäjälle tai projektipäällikölle, joka haluaa tietää, mikä ohjelmistojen entropia on, käytännön vaikutuksista heidän työhönsä ja taustalla oleviin tekijöihin, jotka vaikuttavat sen kasvuun.

Ensisijainen tavoite on luoda tietoisuus ohjelmistojen entropiasta koska se on tekijä kaikissa ohjelmistokehityksen muodoissa. Lisäksi tutkimme tapaa, jolla ohjelmistojen entropialle voidaan antaa konkreettinen arvo. Vain kvantifioimalla ohjelmistojen entropia ja tarkkailemalla niiden kasvua peräkkäisissä julkaisuissa voimme todella ymmärtää riskin, jonka se aiheuttaa nykyisille tavoitteillemme ja tuleville suunnitelmillemme.

Mikä on ohjelmiston entropia?

Ohjelmiston entropia on saanut nimensä reaalimaailman entropian pääominaisuudesta: Se on kaaoksen mittari, joka joko pysyy samana tai kasvaa ajan myötä . Toisin sanoen, se on mitta ohjelmistojärjestelmään sisäänrakennetusta epävakaudesta sen muuttamisen suhteen.

Valitettavasti ohjelmistojen entropialle annetaan harvoin ansaitsemansa merkitys.

Sitä ei oteta huomioon, kun vedetään joku kehitystiimistä, aloitetaan ennenaikaisesti kehityskierto tai toteutetaan 'pikakorjauksia' - hetkiä, kun itse asiassa se todennäköisesti kasvaa.

Ohjelmistokehitys on taidetta ja kauppaa, jonka ydinrakenteet ovat huonosti määriteltyjä. Rakentajat työskentelevät sementin ja naulojen kanssa, mutta ohjelmistokehittäjä toimii loogisten väitteiden ja joukon oletuksia. Näitä ei voida pitää kädessä ja tutkia, eikä niitä voida tilata tuuman kahdeksasosaan mennessä. Vaikka satunnaisella tarkkailijalla saattaa olla houkutus verrata ohjelmistokehitystä rakentamiseen, muutaman pinnallisen samankaltaisuuden lisäksi on haitallista tehdä niin.

Näistä vaikeuksista huolimatta voimme silti laatia suuntaviivat, joiden avulla voimme ymmärtää ohjelmistojen entropian lähteet, mitata sen tavoitteisiin kohdistuvan riskin laajuuden ja (tarvittaessa) mitä toimia voidaan toteuttaa sen kasvun rajoittamiseksi.

Ehdotettu ohjelmistojen entropian määritelmä on seuraava:

E = I / C

missä I on johdettu edellisen kehityksen iteraation aikana tuotettujen odottamattomien ongelmien lukumäärästä, C on havaittu todennäköisyys, että järjestelmän muutosten toteuttaminen johtaa nyt uuteen I´> 0: een, ja S on seuraavan kehitystoiminnan laajuus. Yleensä E: n arvoja alle 0,1 pidetään hyvinä. E: n arvoa 0,5 pidetään suurena ja arvot, jotka ovat yli 1,0, ovat ylivoimaisia.

A. Käsite kehityksen iterointi on olennainen osaamisemme ohjelmistojen entropiasta. Nämä ovat aktiivisuussyklejä, jotka johtavat järjestelmän yhdestä käyttäytymisestä toiseen. Tavoitteita, jotka asetamme itsellemme ohjelmistojen toistamisen aikana, kutsutaan sen soveltamisala . Ohjelmistokehityksessä tällaisiin sykleihin liittyy ohjelmiston taustakoodin muokkaaminen tai laajentaminen.

Kaikki koodiin tehdyt muutokset tapahtuvat kehitys iteroinnissa, vaikka niitä suorittavat eivät ajattele niitä tällä tavalla. Toisin sanoen pienemmät organisaatiot, jotka ovat ylpeitä järjestelmiensä rakentamisesta 'nopean ja likaisen' metodologian avulla - vaatimuksia tai analyysejä ei ole kerätty lainkaan tai ei lainkaan - käyttävät edelleen kehitys iteraatioita tavoitteidensa saavuttamiseksi. He eivät yksinkertaisesti suunnittele niitä. Vastaavasti, vaikka muokatun järjestelmän käyttäytyminen poikkeaisi jollakin tavalla aikomuksistamme, se saavutettiin silti kehityksen iteraation avulla.

Itse asiassa tämän tapahtumisen riski on juuri se, mitä tietoomme ohjelmistojen entropiasta on tarkoitus selittää ja haluamme mitata sitä on tarkoitus rajoittaa. Käytännössä voimme sitten määritellä ohjelmistojen entropian seuraavasti.

Jokaisella järjestelmällä on rajallinen joukko tunnettuja, avoimia asioita I₀. Seuraavan kehitysvaihdon lopussa on rajallinen joukko tunnettuja, avoimia kysymyksiä I_yksi. Järjestelmän luontainen entropia määrittää, kuinka paljon odotamme minua_yksitodennäköisesti eroaa todellisesta arvostaan ​​ja siitä, kuinka paljon ero todennäköisesti kasvaa seuraavissa iteraatioissa.

Ohjelmiston entropian vaikutukset

Käytännön kokemuksemme ohjelmistojen entropian vaikutuksista riippuu siitä, miten olemme vuorovaikutuksessa kyseessä olevan järjestelmän kanssa.

Käyttäjillä on staattinen näkymä ohjelmistosta; he ovat huolissaan siitä, miten se käyttäytyy nyt, eivätkä välitä järjestelmän sisäisistä osista. Suorittamalla ennalta määritetyn toiminnon käyttäjät olettavat, että ohjelmisto reagoi vastaavalla ennalta määritetyllä tavalla. Käyttäjät ovat kuitenkin vähiten valmiita päättelemään käyttämänsä ohjelmiston entropian tason.

Ohjelmistojen entropia on sidottu muutoksen käsitteeseen, eikä sillä ole merkitystä staattisessa järjestelmässä. Jos järjestelmää ei ole tarkoitus muuttaa, emme voi puhua sen entropiasta. Samoin järjestelmällä, jota ei vielä ole olemassa (eli seuraava iterointi on itse asiassa ensimmäinen olemassaolostaan), ei ole entropiaa.

Ohjelmisto voidaan nähdä 'bugisena' käyttäjän näkökulmasta, mutta jos seuraavien iterointien aikana ohjelmistokehittäjät ja johtajat saavuttavat tavoitteensa suunnitellusti, meidän on pääteltävä, että järjestelmän entropia on itse asiassa melko alhainen! Käyttäjien kokemus kertoo siis vain hyvin vähän, jos ollenkaan, ohjelmistojen entropiasta:

• Ohjelmistokehittäjillä on sujuva näkymä ohjelmistoista. He ovat huolissaan siitä, miten järjestelmä toimii tällä hetkellä vain siltä osin kuin sitä on muutettava, ja he ovat huolissaan yksityiskohdista, miten se toimii sopivan strategian suunnittelussa.

• Johtajilla on ehkä monimutkaisempi näkymä ohjelmistoista, sekä staattisista että sujuvista. Niiden on tasapainotettava lyhyen aikavälin tarpeet tulevaisuuden liiketoimintasuunnitelman vaatimuksiin.

Molemmissa rooleissa olevilla ihmisillä on odotuksia. Ohjelmistojen entropia ilmenee aina, kun nuo odotukset pilaantuvat. Toisin sanoen ohjelmistokehittäjät ja johtajat tekevät parhaansa arvioidakseen riskit ja suunnitellakseen niitä, mutta lukuun ottamatta ulkoisia häiriöitä, jos heidän odotuksensa ovat kuitenkin pettyneitä, voimme puhua ohjelmistojen entropiasta. Näkymätön käsi rikkoo komponenttien väliset vuorovaikutukset, jotka eivät kuulu soveltamisalaan, saa tuotantopalvelimet kaatumaan selittämättömästi ja pidättää oikea-aikaiset ja kustannustehokkaat hotfix-korjaukset.

Monet järjestelmät, joilla on korkea entropia, riippuvat tietyistä henkilöistä, varsinkin jos kehitystiimissä on nuorempia jäseniä. Tällä henkilöllä on tietoa niin, että muut eivät voi suorittaa tehtäviään ilman hänen 'arvokasta' panostaan. Sitä ei voida kaapata tavallisissa UML-kaavioissa tai teknisissä eritelmissä, koska se koostuu yhdistelmästä poikkeuksia, viittauksia ja vinkkejä. Tämä tieto ei ole riippuvainen loogisesti johdonmukaisesta kehyksestä, ja siksi sitä on vaikea - ellei mahdotonta - siirtää kenellekään muulle.

Oletetaan, että tällainen organisaatio pystyy suurella päättäväisyydellä ja vaivalla kääntymään ympäriinsä ja vakauttamaan IT-osastonsa. Tilanne näyttää parantuneen, koska kun ohjelmistokehitys on pysähtynyt, mikä tahansa edistys on rohkaisevaa. Todellisuudessa odotukset, joita täytetään, ovat pieniä ja saavutukset mielenkiintoisia verrattuna korkeisiin tavoitteisiin, jotka olivat saavutettavissa, kun entropia oli vielä matala.

Kun ohjelmistoentropia ylittää projektin, projekti jäätyy.

Kehityskertoja ei voi enää olla. Onneksi tätä tilannetta ei synny välittömästi. Hidas, mutta sykkivä marssi kohti kallion reunaa on jokaisen järjestelmän läpi. Riippumatta siitä, kuinka hyvin organisoitu ja tehokas ensimmäinen versio on, peräkkäisissä kehitysvaiheissa toistetaan sen entropia - ja siten riski odottamattomasta pieleen - kasvaa, ellei erityisiä toimenpiteitä sen estämiseksi toteuteta.

Ohjelmistojen entropiaa ei voida vähentää. Aivan kuten entropia todellisessa maailmassa, se vain kasvaa tai pysyy samana. Aluksi sen vaikutukset ovat vähäisiä. Kun ne alkavat ilmetä, oireet ovat lieviä ja ne voidaan peittää tai jättää huomiotta. Mutta jos organisaatio yrittää torjua ohjelmistojen entropiaa vasta sen jälkeen, kun siitä on tullut hallitseva riski projektissa, se valitettavasti huomaa, että sen ponnistelut ovat turhia. Tieto ohjelmistojen entropiasta on siis kaikkein hyödyllisintä, kun sen laajuus on vähäinen ja haitalliset vaikutukset vähäiset.

Tästä ei seuraa, että jokaisen organisaation tulisi käyttää resursseja tuotteidensa entropian kasvun rajoittamiseen. Suurella osalla nykyään kehitettävistä ohjelmistoista - erityisesti kuluttajakeskeisistä ohjelmistoista - on suhteellisen lyhyt odotettu käyttöikä, ehkä muutama vuosi. Tässä tapauksessa sen sidosryhmien ei tarvitse ottaa huomioon ohjelmistojen entropian vaikutuksia, koska siitä tulee harvoin vakava este, ennen kuin koko järjestelmä hylätään. Ohjelmistojen entropian vaikutusten huomioon ottamiseksi on kuitenkin vähemmän ilmeisiä syitä.

Harkitse ohjelmistoa, joka käyttää Internetin reititysinfrastruktuuria tai siirtää rahaa pankkitililtä toiselle. Kulloinkin tuotannossa on yksi tai useampi versio ohjelmistosta, ja niiden kollektiivinen käyttäytyminen voidaan dokumentoida kohtuullisen suurella tarkkuudella.

riskitoleranssi Järjestelmän mitta on kuinka paljon ja minkä tyyppistä odottamatonta käyttäytymistä voimme mukavasti sallia yhdestä kehitysvaiheesta toiseen. Äskettäin mainittujen järjestelmätyyppien riskitoleranssi on paljon pienempi kuin puheluita ohjaava ohjelmisto. Tällä ohjelmistolla puolestaan ​​on alhaisempi riskinsietokyky kuin ohjelmistolla, joka ajaa monien kaupallisten verkkosivustojen ostoskoria.

Riskisietokyky ja ohjelmistojen entropia liittyvät toisiinsa siinä, että ohjelmistojen entropian on oltava vähäistä, jotta voimme olla varmoja siitä, että pysymme järjestelmän riskitoleranssissa seuraavan kehityksen iteraation aikana.

Ohjelmiston entropian lähteet

Ohjelmistojen entropia syntyy tiedon puute . Se johtuu yhteisöolettamiemme ja olemassa olevan järjestelmän todellisen käyttäytymisen välisestä erosta. Tämä selittää, miksi ohjelmistoentropialla on merkitystä vain olemassa olevan järjestelmän muokkaamisen yhteydessä; tällä kertaa ymmärryksen puutteellamme on käytännön vaikutuksia. Ohjelmistoentropia löytää hedelmällisimmän pohjan järjestelmässä, jonka yksityiskohtia ei voida ymmärtää yhdelle henkilölle, vaan se on levinnyt kehitystiimin ympärille. Myös aika on voimakas tiedon pyyhkijä.

Koodi ilmaisee sarjan loogisia väitteitä. Kun ohjelmiston käyttäytyminen (ja siten sen koodi) ei vastaa logiikkaa, jonka sen on tarkoitus ilmaista, voimme puhua sen luontaisesta entropiasta. Tämä tilanne voi syntyä kolmella tavalla: Logiikka on hyvin tunnettu ja poikkeaa lausekkeestaan, on useita käsityksiä logiikasta, jonka koodi on tarkoitettu ilmaisemaan, tai logiikka ei ole hyvin tunnettua.

• Ensimmäinen tilanne - logiikka on hyvin tiedossa ja poikkeaa nykyisestä lausekkeestaan ​​- on helpoin käsitellä, mutta myös vähiten yleinen. Vain hyvin pienet järjestelmät, joita ylläpitää ehkä kaksi osallistujaa, kehittäjä ja joku liiketoimintasuunnitelmasta vastaava, kuuluvat tähän luokkaan.

• Toinen tilanne - logiikkaa ei tunneta hyvin - on harvinaista. Kaikista syistä kehityksen iterointi ei voi edes alkaa. Jos jossain vaiheessa kaikki sidosryhmät voivat sopia, he todennäköisesti kohtaavat ensimmäisen tilanteen.

Ihmisen mieli tulkitsee kokemuksensa suodattamalla ja muokkaamalla niitä tehokkaasti yrittäen sovittaa ne henkilökohtaiseen kehykseen. Tehokkaiden kehitystottumusten puuttuessa - jotka perustuvat vapaaseen ajatustenvaihtoon, keskinäiseen kunnioitukseen ja selkeisiin odotuksiin - tulkintoja järjestelmän toiminnasta voi olla yhtä monta kuin ryhmän jäseniä. Joukkueen tavoitteet nykyiselle kehitysvaiheelle voivat itse olla kiistanalaisia.

Monet kehittäjät suojaavat itseään tältä tilanteelta vahvistamalla omaa ainutlaatuista käsitystään siitä, mitä heiltä vaaditaan ja kuinka järjestelmän tulisi 'olla' organisoitu. Toisaalta johtajat ja muut sidosryhmät saattavat tahattomasti yrittää muuttaa muiden tiimin jäsenten oletuksia harhaanjohtamalla yrittäessään helpottaa omaa elämäänsä.

Olemme nyt päässeet yleisimpään ohjelmistojen entropian lähteeseen: Järjestelmän on tarkoitus ilmaista useita, epätäydellisiä tulkintoja logiikasta. Koska tällä logiikalla on vain yksi ilmentymä, tilanne on määritelmän mukaan ongelmallinen.

Kuinka tämä tiedon puute syntyy? Epäpätevyys on yksi tapa. Ja kuten olemme jo nähneet, sopimusten puute seuraavan kehitys iteraation tavoitteista on toinen asia. Mutta on muitakin tekijöitä, jotka on otettava huomioon. Organisaatio voi pyrkiä käyttämään kehitysmenetelmiä, mutta sitten hylkäämään sattumanvaraisesti osan tai kaikki sen näkökohdat lattialla. Ohjelmistokehittäjille annetaan sitten tehtävä epämääräisiä tehtäviä, jotka ovat usein tulkinnanvaraisia. Organisaatiot, jotka toteuttavat muutoksia kehitysmenetelmiinsä, ovat erityisen alttiita tälle ilmiölle, vaikka ne eivät ole suinkaan ainoat. Henkilökohtaiset ristiriidat, joista johto ei ole tietoinen tai joita muuten ei pystytä ratkaisemaan, voivat myös johtaa vaarallisiin eroihin odotusten ja tulosten välillä.

On toinen, tärkeämpi tapa menettää tekninen tieto tuotteesta: siirto. Teknisen tiedon kerääminen paperille on haastavaa myös taitavimmille kirjailijoille. Syynä on se mitä litteroida on yhtä tärkeää kuin Miten . Ilman asianmukaista kurinalaisuutta tekninen kirjoittaja voi tallentaa liikaa tietoa. Vaihtoehtoisesti he voivat tehdä oletuksia, jotka saavat heidät jättämään pois olennaiset kohdat. Sen jälkeen, kun tekninen dokumentaatio on laadittu, se on pidettävä huolellisesti ajan tasalla, mikä on vaikea ehdotus monille organisaatioille, jotka menettävät asiakirjojaan melkein heti niiden kirjoittamisen jälkeen. Näiden vaikeuksien takia teknistä tietoa siirretään harvoin pelkästään asiakirjoissa, mutta myös pariliitoksina tai muussa läheisessä ihmissuhteessa tapahtuvassa vuorovaikutuksessa.

Ohjelmistojen entropia tekee harppauksia aina, kun aktiivinen osallistuja poistuu kehitystiimistä. He ottavat mukanaan arvokkaan osaamisen. Tämän taitotiedon jäljentäminen on mahdotonta, ja sen lähentäminen vaatii huomattavia ponnisteluja. Riittävän huomion ja resurssien avulla voidaan kuitenkin säilyttää riittävä tieto siitä, että järjestelmän entropian kasvu voidaan minimoida.

Entropialle on muita lähteitä, mutta nämä ovat suhteellisen vähäisiä. Esimerkiksi ohjelmistojen mätäneminen on prosessi, jossa ympäristöön tehdyt muutokset vaikuttavat odottamattomasti järjestelmään. Voimme ajatella kolmannen osapuolen ohjelmistoja, joihin se perustuu (kuten kirjastot), mutta ohjelmistojen mädäntämiseen on muitakin salakavalampia syitä, jotka yleensä johtuvat järjestelmän perustana olevien oletusten muutoksista. Esimerkiksi, jos järjestelmä on suunniteltu tietyillä oletuksilla muistin saatavuudesta, se voi alkaa toimia virheellisesti odottamattomissa hetkissä, jos sen käytettävissä oleva muisti on vähentynyt.

Kuinka laskea entropia: Arvojen osoittaminen C: lle, S: lle ja I: lle

I on ratkaisemattomien käyttäytymisongelmien määrä ohjelmistojärjestelmässä, mukaan lukien luvattujen ominaisuuksien puuttuminen. Tämä on tunnettu määrä, jota seurataan usein järjestelmässä, kuten JIRA . I´: n arvo johdetaan suoraan siitä. I on niiden 'työyksiköiden' lukumäärä, jotka hylättiin tai jätettiin keskeneräisiksi viimeisen kehityksen iteraation aikana, uusien työtilojen lukumäärän lisäksi, jotka johtuvat uusista ja odottamattomista käyttäytymisongelmista. Koska minut lasketaan työyksikköjen lukumääräksi, voimme liittää sen S: n arvoon, joka on seuraavan kehitysvaihdon laajuus samoissa työyksiköissä. Mikä tarkalleen käsittää 'työyksikön', riippuu kehitysmenetelmistä.

C on havaittu todennäköisyys, että kun soveltamisalaan kuuluvat työyksiköt on toteutettu, varsinaisten avoimien kysymysten lukumäärä I1 seuraavalla iteraatiolla on suurempi kuin sen nyt arvioima. Tämä arvo asuu verkkotunnuksessa 0<= C <= 1.

Voidaan väittää, että todennäköisyys C on juuri se, mitä ohjelmistoentropian tarkoituksena on mitata. Tämän arvon ja ohjelmistoentropian mittauksen välillä on kuitenkin perustavanlaatuisia eroja. koettu todennäköisyys, että jokin menee pieleen, on täsmälleen sama: Se ei ole todellinen arvo. Se on kuitenkin hyödyllinen siinä mielessä, että projektiin osallistuvien ihmisten tunteet ovat arvokas tietolähde siitä, kuinka vakaa se on.

Laajuus S ottaa huomioon ehdotettujen muutosten suuruuden ja on ilmaistava samoissa yksiköissä kuin I´. Suurempi S: n arvo vähentää entropiaa, koska laajennamme ehdotettujen muutosten laajuutta. Vaikka tämä saattaa kuulostaa epäluuloiselta, meidän on pidettävä mielessä, että entropia on mittari siitä, miten järjestelmän kehitys voi tapahtua ei vastaamaan odotuksiamme. Ei riitä, että sanotaan, että entropia on mitta mahdollisuudesta aiheuttaa ongelmia. Yritämme luonnollisesti ennakoida riskejä ja ottaa ne huomioon suunnittelussa (ja siten myös arviossa I1, joka voi hyvinkin nousta yli₀). On selvää, että mitä varmemmin suhtaudumme laajaan muutosalueeseen, sitä vähemmän entropian voidaan sanoa olevan järjestelmässä - elleivät muutosten suunnittelijat ja / tai niiden toteuttajat ole epäpäteviä. Tämä mahdollisuus heijastuu kuitenkin todennäköisesti I´: n nykyarvoon.

Huomaa, että meidän ei tarvitse yrittää määrittää I: n todellisen arvon välisen eron suuruutta_yksija sen odotettu arvo. Jos oletamme, että suunnitelmamme ovat oikeita, kun teemme ne, ei ole myöskään järkevää olettaa, että voimme ennustaa, missä määrin tulos ei vastaa odotuksiamme; voimme määrittää vain havaitun mahdollisuuden C, jota se ei tee. Todellisen arvon I aste_yksieroaa odotetusta arvostaan, on tärkeä panos entropian laskemiseen seuraavalla iteraatiolla johdetun arvon I´ muodossa.

Teoriassa on mahdollista, että minulla on negatiivinen arvo. Käytännössä tätä tilannetta ei kuitenkaan koskaan tapahdu; emme yleensä ratkaise ongelmia vahingossa. Minun negatiiviset arvot eivät ole lohduttava merkki. Ne tarkoittavat, että keinot, joilla entropia lasketaan, ovat virheelliset. Ohjelmistojen entropian kasvua voidaan tietysti vähentää toteuttamalla erityisiä toimenpiteitä, kuten alla kuvataan. Tällaisissa tapauksissa minun ei kuitenkaan pitäisi olettaa negatiivisia arvoja, koska sisällytämme odotuksemme aina malleihimme.

C on subjektiivinen arvo. Se on olemassa kehitys iteraation osallistujien mielessä, ja se voidaan päätellä kyselyllä ja tulosten keskiarvolla. Kysymys on esitettävä positiivisella tavalla. Esimerkiksi: 'Kuinka arvioisit asteikolla 0-10 ja 10 todennäköisimmin joukkueen mahdollisuudet saavuttaa kaikki tavoitteet tässä kehitysvaiheessa?'

Huomaa, että kysytään ryhmän tavoitteista kokonaisuutena, ei osajoukoista. Vastaus 10 osoittaisi C: n arvon 0, kun taas vaste 7 osoittaisi arvon .3. Suuremmissa ryhmissä jokainen vastaus voidaan painottaa riippuen asiaankuuluvista tekijöistä, kuten kuinka kauan henkilö on ollut mukana projektissa ja kuinka suuri osa ajastaan ​​siihen todella kulutetaan. Pätevyyden ei kuitenkaan pitäisi olla tekijä painotettaessa vastauksia. Ennen pitkää jopa tiimin nuorimmalla jäsenellä on käsitys siitä, kuinka tehokkaasti se on tavoitteidensa saavuttamisessa. Riittävän suuret joukkueet saattavat haluta hylätä korkeimmat ja matalimmat ilmoitetut arvot ennen lopun keskiarvon laskemista.

Arkaluonteinen ja provosoiva ehdotus on kysyä ammattilaisilta, kuinka todennäköisesti heidän tiiminsä epäonnistuu. Tämä on kuitenkin juuri kysymys, jonka jokaisen organisaation, joka haluaa mitata entropiaa, on esitettävä. Rehellisten vastausten varmistamiseksi osallistujien tulisi antaa arvio C: stä nimettömästi ja pelkäämättä seurauksia, vaikka he ilmoittaisivatkin kohtalokkaasti korkean arvon.

S: lle on annettava arvo samoissa 'työyksiköissä' kuin minä, ja siksi se on hyvin riippuvainen kehitysmenetelmistä. Joukkueille, jotka käyttävät Ketterä metodologia , tarinat näyttävät ilmeisimmältä ”työyksiköltä” sekä S: lle että minulle. Tässä tapauksessa kehitys iteroinnin laajuus ulottuu jokaiseen säännöllisesti suunniteltuun tuotantoon, joko pieneen tai suurempaan. Minut on laskettava määränä niiden tarinoiden lukumääränä, joita ei saatu päätökseen jokaisen julkaisuun johtavan sprintin aikana, ja niiden tarinoiden lukumääränä, jotka on luotu sisällytettäviksi tuleviin sprintteihin julkaisun jälkeen ilmenneiden odottamattomien ongelmien seurauksena.

Huomaa, että emme pidä hotfix-korjauksia tai muita ennakoimattomia julkaisuja tuotantoon määrittelemällä kehitys iteroinnin laajuutta, emmekä pidä vähentää I: stä mitään siihen liittyviä tarinoita.

Tämän lähestymistavan vaikeus on, että löytö- ja analyysijakson on tapahduttava, ennen kuin virheet voidaan myöhemmin jakaa tarinoihin. I: n todellinen arvo voidaan siis määrittää vasta viiveen jälkeen. Lisäksi C: n kysely tapahtuu luonnollisesti jokaisen sprintin alussa. Saadut tulokset on siis jälleen keskiarvotettava koko vapautumisen ajan. Näistä vaikeuksista huolimatta kaikki ryhmät, jotka käyttävät ketterän menetelmän näkökohtia, havaitsevat todennäköisesti, että tarinat ovat tarkin yksikkö S: n (ja siksi minä) kvantifioimiseksi.

Nykyään on muitakin kehitysmenetelmiä käytössä. Käytetystä menetelmästä riippumatta ohjelmistojen entropian mittaamisen periaatteet pysyvät ennallaan: Ohjelmistojen entropia tulisi mitata tuotantoon julkaisemisen välillä, S ja I mitataan samoissa 'työyksiköissä' ja arviot C: stä olisi otettava suorilta osallistujilta vaarattomalla ja mieluiten nimettömällä tavalla.

E: n kasvun vähentäminen

Kun tieto järjestelmästä on kadonnut, sitä ei voida enää palauttaa. Tästä syystä ohjelmistojen entropiaa ei voida vähentää. Ainoa mitä voimme toivoa, on hillitä sen kasvua.

Entropian kasvua voidaan rajoittaa toteuttamalla asianmukaiset toimenpiteet ohjelmistokehityksen aikana. Ketterän kehityksen pariohjelmointi on erityisen hyödyllinen tässä suhteessa. Koska aikakoodin kirjoittamisen aikana on mukana useita kehittäjiä, keskeisten yksityiskohtien tuntemus jaetaan ja lähtevien tiimin jäsenten vaikutuksia lievennetään.

Toinen hyödyllinen käytäntö on hyvin jäsenneltyjen ja helposti kulutettavien asiakirjojen tuottaminen erityisesti vesiputousmenetelmiä käyttävissä organisaatioissa. Tällaisen dokumentoinnin on oltava tiukkojen ja hyvin määriteltyjen periaatteiden mukaista, jotka kaikki ymmärtävät. Organisaatiot, jotka luottavat dokumentointiin ensisijaisena viestintävälineenä ja turvaavat teknisen tiedon, soveltuvat hyvin tähän lähestymistapaan. Vasta kun niitä on ei ohjeet tai koulutus sisäisesti kirjoitettujen asiakirjojen kirjoittamisesta ja käytöstä - kuten usein tapahtuu nuoremmissa organisaatioissa, jotka käyttävät RAD- tai ketteriä menetelmiä - että heidän arvostaan ​​epäillään.

On olemassa kaksi tapaa vähentää entropian kasvua järjestelmässä: Suorita muutokset I: n vähentämiseksi tai suorita muutokset C: n vähentämiseksi.

Ensimmäiseen liittyy refactoring. Vähentämiseen tähtäävät toimet olen yleensä luonteeltaan tekninen ja luultavasti jo lukijalle tuttu. Kehityksen iteroinnin on tapahduttava. Tämän iteraation osa, jonka on tarkoitus vähentää entropian kasvua ei tuota konkreettisia liiketoimintahyötyjä kun se kuluttaa aikaa ja resursseja. Tämä tosiasia tekee entropian kasvun vähentämisestä kovaa myyntiä missä tahansa organisaatiossa.

C-arvon alentaminen on tehokkaampi strategia, koska vaikutus on pidempi. Lisäksi C toimii tärkeänä tarkistuksena I: n ja S: n suhteen kasvulle. C: n vähentämistä koskevat toimet keskittyvät yleensä ihmisen käyttäytymiseen ja ajatteluun. Vaikka nämä toimet eivät välttämättä vaadi kehityksen iterointia sinänsä, ne hidastavat seuraavia iteraatioita, kun osallistujat hyväksyvät ja sopeutuvat uusiin menettelyihin. Näennäisesti yksinkertainen tapa sopia parannuksista, jotka on tehtävä, on polku, joka on täynnä omia vaaroja, kun projektin osallistujien ja sidosryhmien erilaiset tavoitteet tulevat yhtäkkiä esiin.

Käärimistä

Ohjelmistojen entropia on riski, että olemassa olevien ohjelmistojen vaihtaminen johtaa odottamattomiin ongelmiin, täyttämättömiin tavoitteisiin tai molempiin.

Vaikka ohjelmistojen ensimmäisessä luomisessa on vähäpätöinen, ohjelmistojen entropia kasvaa jokaisen kehityksen iteraation mukana. Jos sen sallitaan etenemättömänä, ohjelmistojen entropia lopulta pysäyttää jatkokehityksen.

Kaikkien projektien ei kuitenkaan tule ottaa huomioon ohjelmistoentropian vaikutuksia. Monet järjestelmät poistetaan tuotannosta, ennen kuin entropialla voi olla huomattavia ja vahingollisia vaikutuksia. Niille, joiden elinaika on riittävän pitkä, jotta entropia aiheuttaa uskottavan riskin, tietoisuuden luominen sille ja sen laajuuden mittaaminen, vaikka se onkin vielä vähäistä, tarjoaa keinon varmistaa, ettei kehitystä keskeytetä ennenaikaisesti.

Kun ohjelmistoentropian vaikutukset ovat hukuttaneet järjestelmän kokonaan, muutoksia ei voida enää tehdä ja kehitys on olennaisesti päättynyt.

Perustietojen ymmärtäminen

Mikä on entropian määritelmä?

Tietojärjestelmien kaaos, joka joko pysyy samana tai kasvaa ajan myötä.

Mikä on ohjelmistojen entropia?

Ohjelmistojen entropia on riski, että olemassa olevien ohjelmistojen vaihtaminen johtaa odottamattomiin ongelmiin, täyttämättömiin tavoitteisiin tai molempiin. Vaikka ohjelmistojen ensimmäisessä luomisessa on vähäpätöinen, ohjelmistojen entropia kasvaa jokaisen kehityksen iteraation mukana.

Kuinka lasken entropian?

E = IC / S, jossa I on johdettu edellisen kehityksen iteraation aikana esiintyneiden odottamattomien ongelmien lukumäärästä, C on havaittu todennäköisyys, että järjestelmän muutosten toteuttaminen johtaa nyt uuteen I´> 0, ja S on seuraavan iteraation laajuus.