Prije nekog vremena vodio se razgovor između mene i mog dobrog prijatelja u kojem su se čule sljedeće fraze:
— Broj programera će stalno rasti - jer količina koda raste, a sve više i više programera stalno je potrebno da ga podržavaju.
— Ali kôd stari, neki od njih više nisu podržani. Čak je moguće da postoji neka vrsta ravnoteže.
Prisjećajući ih se nekoliko dana kasnije, zapitao sam se može li održavanje koda, koji s vremenom zahtijeva sve više i više resursa, u konačnici paralizirati razvoj novih funkcionalnosti ili bi to zahtijevalo neograničeno povećanje broja programera? Matematička analiza i diferencijalne jednadžbe pomogle su da se kvalitativno ocijeni ovisnost visine potpore o razvoju i pronađu odgovori na pitanja.
Pitanje jedno. Može li podrška “pojesti” sve razvojne resurse?
Zamislite tim programera u kojem je broj sudionika konstantan. Udio njihovog radnog vremena 
() troši se na razvoj novog koda, a preostali dio vremena ide u podršku. Unutar pretpostavki modela pretpostavljamo da je prva vrsta aktivnosti usmjerena na povećanje volumena koda, a druga je usmjerena na njegovu promjenu (ispravljanje grešaka) i nema značajan utjecaj na volumen koda.
Označimo cjelokupnu količinu koda napisanu do te točke u vremenu . Pod pretpostavkom da je brzina pisanja koda proporcionalna , dobivamo:
Prirodno je pretpostaviti da su troškovi rada za održavanje koda proporcionalni njegovom volumenu:
ili
Odakle
Dobivamo diferencijalnu jednadžbu koja se lako integrira. Ako je u početnom trenutku vremena količina koda nula, tada
u funkcija I . A to znači postupno smanjivanje razvoja novih funkcionalnosti na nulu i prijenos svih resursa na podršku.
Međutim, ako tijekom vremena kod postaje zastario i prestaje biti podržan, zatim količina koda koja zahtijeva podršku u jednom trenutku već je jednaka Zatim
а je rješenje diferencijalne jednadžbe s retardiranim argumentom [1]:
Rješenje takve jednadžbe je jedinstveno određeno zadavanjem vrijednosti "prije početka vremena" . Budući da kôd još nije bio napisan prije početnog trenutka u vremenu, u našem slučaju na .
Pogledajmo nekoliko primjera. Vrijeme ćemo mjeriti u godinama, a količinu koda u tisućama linija. Zatim za prihvatljive su vrijednosti reda desetaka, uzet ćemo 50 i 100. To jest, u godinu dana razvojni tim će napisati pedeset, odnosno sto tisuća redaka koda. Za prihvatljive vrijednosti mogu biti: , , . To znači da razvojni tim može podržati količinu koda koju napiše u jednoj godini, bilo da je to četvrtina, pola ili puno radno vrijeme. Kao prosječni životni vijek koda postavit ćemo sljedeće vrijednosti: 1, 2 i 4 godine. Numeričkim rješavanjem jednadžbe dobivamo primjere ponašanja funkcije za neke kombinacije parametara .
Ponašanje funkcije kako kod stari, mijenjao se. Funkcija više nije monotona, već se fluktuacije s vremenom „smiruju“ i postoji tendencija na neku konstantnu vrijednost. Grafikoni pokazuju: što više , и , odnosno što kod sporije stari, što je brži razvoj novog koda i što je kvaliteta koda niža, to će manje resursa ostati za razvoj nove funkcionalnosti. Postojala je želja da se navede barem jedan primjer u kojem “ušuljao” blizu nule. Ali to je zahtijevalo odabir vrlo loših pokazatelja kvalitete razvoja i koda koji dugo ne stari. Čak iu donjem lijevom grafikonu ostaje značajna količina resursa za novu funkcionalnost. Stoga je točan odgovor na prvo pitanje otprilike sljedeći: teoretski - da, moguće je; praktično - jedva.
Pitanja na koja nije bilo moguće odgovoriti:
- Je li istina da teži nekoj granici na za sve ? Ako ne za sve, onda za koje?
- Ako ograničenje postoji, o čemu ovisi njegova vrijednost ?
Drugo pitanje. Može li održavanje koda uzrokovati neograničeni rast broja programera?
Označimo broj programera uključenih u razvoj novog koda. Kao gore, — količina koda napisanog do određenog trenutka , tada
Neka podrška za kod bude zaposlena programeri. Uzimajući u obzir šifru starenja,
Odakle
Ako tada
Dakle, odgovor na drugo pitanje je negativan: ako je broj programera novog koda ograničen, tada u uvjetima starenja koda podrška ne može uzrokovati neograničeno povećanje broja programera.
Zaključak
Razmatrani modeli su "meki" matematički modeli [2]. Vrlo su jednostavni. Unatoč tome, ovisnost rezultata simulacije o vrijednostima parametara odgovara onome što se očekuje za stvarne sustave, što govori u prilog adekvatnosti modela i dovoljnoj točnosti za dobivanje visokokvalitetnih procjena.
reference
1. Elsgolts L.E., Norkin S.B. Uvod u teoriju diferencijalnih jednadžbi s odstupajućim argumentom. Moskva. Izdavačka kuća "Science". 1971. godine.
2. Arnold V.I. “Tvrdi” i “meki” matematički modeli. Moskva. Izdavačka kuća MCNMO. 2004. godine.
Izvor: www.habr.com