Szoftverkarbantartás Költsége: Amit Senki Nem Tervez Be

A szoftverkarbantartás költsége az a szám, amely egy sikeres projektet tizennyolc hónappal később kellemetlen beszélgetéssé változtat. A fejlesztésre volt keret, jóváhagyás és átadás. Azt, ami az élesítés után következik, valaki egyszerűen „támogatásnak" nevezte, és egy hasra ütéssel megbecsült összeget rendelt hozzá, ez az összeg pedig szinte mindig túl kevés volt.

Az ok szerkezeti, nem hanyagság kérdése. Egy fejlesztésnek van terjedelme, amit be lehet árazni. A karbantartásnak nincs terjedelme, mert olyan dolgok határozzák meg, amelyek még meg sem történtek: egy sérülékennyé váló programkönyvtár, egy beszállító, aki átalakítja az API-ját, egy felhasználó, aki olyan esetbe fut bele, amire senki sem számított.

A mindenki által idézett ökölszabály szerint a fejlesztési költség 15 vagy 20 százaléka évente, és éppen attól veszélyes, hogy majdnem igaz. Elég sokszor stimmel ahhoz, hogy biztonságérzetet adjon, és kiszámítható irányba téved: alábecsüli az első évet, amikor a hibák felszínre jönnek, és teljesen összeomlik a szabályozott kötelezettségekkel vagy sok külső integrációval működő rendszereknél, ahol a munkát külső események indítják el, nem a saját kódbázis.

Mit fed le valójában a szoftverkarbantartás költsége

Öt jól elkülöníthető kategória, és éppen ezek összekeverése szüli a rossz számot.

Hibajavítás. A defektusok kijavítása. Az elejére sűrűsödik, mert a hibák nagy része a valódi használat első hónapjaiban jön elő, és ezt a kategóriát kezeli a legjobban a százalékos szabály.

Alkalmazkodás. Lépést tartani azzal, ami nem a te kezedben van. Egy függőség biztonsági javítást ad ki. Egy fizetési szolgáltató kivezet egy API-verziót. Egy böngésző megváltoztatja a viselkedését. Ezek egyike sem ad új funkciót, és mindegyik kötelező.

Megelőzés. Frissíteni, mielőtt rákényszerülnél. Ha kihagyod, a költség nem tűnik el, csak elhalasztódik és felkamatozik, és így lesz egy rutin keretrendszer-frissítésből három hónapos projekt.

Üzemeltetés. Tárhely, felügyelet, mentések, tanúsítványok, és az emberi idő, amely mindezt figyeli. Gyakran külön könyvelik, ami rendben is van, amíg egyáltalán könyveli valaki.

Apró módosítások. Az igazításoknak az az egyenletes folyama, amit egy élő rendszer termel, amint valódi felhasználók dolgoznak benne. Külön-külön jelentéktelenek, együttvéve viszont a legtöbb évben ez a legnagyobb tétel.

Csak az első az, amit az emberek karbantartás alatt érteni szoktak. A másik négy miatt fogy el a keret.

Miért vezet félre a százalékos szabály

Rossz mennyiséghez horgonyoz. A karbantartási ráfordítást a mozgó alkatrészek száma és az szabja meg, hogy a külvilág milyen ütemben változtatja meg őket, nem az, hogy a fejlesztés véletlenül mennyibe került.

Két azonos pénzből épített rendszer között háromszoros különbség is lehet. Egy önmagában zárt alkalmazás két függőséggel és szabályozási kitettség nélkül olcsón tartható működésben. Egy olyan rendszer viszont, amely hat külső szolgáltatást fűz össze, személyes adatokat kezel és ágazati szabályok alá esik, már nem, mert minden egyes integráció olyan munka forrása, amelyet nem te ütemezel.

A százalék ráadásul olyan egyensúlyi állapotot feltételez, amely az első évben nem létezik. A valódi használat megtalálja a hibákat, és az indulás utáni első hat hónap jellemzően jóval az éves átlag fölött van, mielőtt a helyzet megnyugodna.

A jobb becslés a mozgó alkatrészekből indul ki. Számold össze az integrációkat, a megfelelőségi kötelezettségeket és azoknak a felhasználóknak a számát, akik támogatási megkereséseket generálnak, majd árazd be a valóságosan ráfordítandó időt. Az egyedi szoftverfejlesztés költségeiről szóló útmutatónk ugyanennek a számításnak az építési oldalát járja körbe.

A tételek, amelyeket a csapatok kifelejtenek

Függőségek frissítése. Nem választható, mert a foltozatlan programkönyvtárak a rendszerek feltörésének fő útja, a ráfordítás pedig valóban kiszámíthatatlan, hiszen attól függ, mit tesznek a csomagok karbantartói.

Külső API-k változásai. Egy beszállító kivezet egy verziót, és határidőt szab. Az időzítést nem te választottad, és nem is utasíthatod vissza.

Tanúsítványok és domainek megújítása. Jelentéktelen egészen addig, amíg az egyik hétvégén le nem jár, és az oldal el nem érhetetlenné válik.

Felügyelet és a rá adott válasz. A riasztás semmit sem ér, ha nincs, aki reagáljon rá, és ez a rendelkezésre állás valódi költség, akár elromlik valami, akár nem.

Tudásátadás. Az emberek elmennek. Amennyibe a következő embernek kerül megérteni a rendszert, az karbantartási költség, és annál nagyobb, minél kevesebbet írtak le.

Az adatok növekedése. A tárolás ára emelkedik, a korábban gyors lekérdezések lassulnak, az ezzel járó munka pedig a saját sikered szabta ütemben érkezik. Az adatbázis-teljesítményről szóló útmutatónk megmutatja, hogy ez a gyakorlatban hogyan néz ki.

Mennyibe kerül ez az Egyesült Királyságban

Hozzávetőleges éves sávok egy egyedi rendszer karbantartására, külső szolgáltatót feltételezve saját alkalmazottak helyett.

Ezek nem tartalmazzák a tárhelyet és a licenceket, amelyeket külön számláznak, és amelyek roppant széles sávban mozognak. Azt is feltételezik, hogy a rendszer elfogadható állapotban van. Olyasmit karbantartani, amit senki nem dokumentált, tesztek nélkül, egyetlen emberrel, aki érti, többe kerül, és olyan kockázatot hordoz, amelyet semmilyen átalánydíj nem szüntet meg.

Hogyan érdemes felépíteni

Az átalánydíj meghatározott óraszámmal akkor működik, ha a mennyiség nagyjából kiszámítható. Rendelkezésre állást vásárolsz, és többnyire pontosan ezért fizetsz; a fel nem használt órák nem vesznek kárba, mert az alternatíva az, hogy nincs senki.

Az idő és anyag alapú elszámolás a keveset változó rendszerekhez illik, a válaszidő viszont annyi lesz, amennyit a szolgáltató egyéb kötelezettségei engednek, és ez az ára.

A fix díjas támogatási szerződés a szolgáltatóra tolja a kockázatot, aki azt beárazza a díjba. Kritikus rendszereknél ésszerű, ahol a kiszámíthatóság többet ér, mint az árrés.

Bármelyiket választod, még azelőtt állapodj meg abban, mi számít karbantartásnak és mi új funkciónak, hogy szükséged lenne rá. Ez a határvonal szinte minden támogatási vita forrása, és a kezdet kezdetén semmibe sem kerül tisztázni.

A Mecanik olyan rendszereket is karbantart, amelyeket nem mi építettünk, ugyanúgy, mint a sajátjainkat, szoftverfejlesztési munkánk részeként. Egy átvétel első hónapja rendszerint dokumentálással telik, mert ez határozza meg az utána következő összes hónap költségét.

Kapcsolódó olvasnivaló: Fix áras szerződés vagy idő és anyag? , Hogyan írj olyan szoftveres ajánlatkérést, amire használható árajánlat érkezik , Szoftverletét: kinek van rá valóban szüksége és MVP-szoftverfejlesztés: terjedelem, költség és ütemterv .

Gyakran ismételt kérdések

Mennyibe kerül évente a szoftverkarbantartás? A szokásos ökölszabály a fejlesztési költség 15 vagy 20 százalékát mondja évente, de alábecsüli az első évet, amikor a hibák felszínre jönnek, és teljesen csődöt mond a sok integrációval vagy szabályozási kötelezettséggel működő rendszereknél. A hozzávetőleges brit sávok £6 000 és £15 000 között kezdődnek egy kis belső eszköznél, és £60 000 fölé mennek egy szabályozott vagy nagy forgalmú platformnál, a tárhely nélkül.

Mit tartalmaz valójában a szoftverkarbantartás? Öt kategóriát: a hibajavítást, az alkalmazkodást a függőségek és a külső API-k változásaihoz, a megelőzést, vagyis a frissítést azelőtt, hogy rákényszerülnél, az üzemeltetést a tárhellyel és a felügyelettel együtt, valamint az apró módosítások állandó folyamát, amelyet egy élő rendszer termel. Csak az első az, amit a legtöbben karbantartás alatt értenek.

Miért megbízhatatlan a fejlesztési költség százalékára épülő szabály? Rossz mennyiséghez horgonyoz. A karbantartási ráfordítást a mozgó alkatrészek száma és a külvilág változtatásainak üteme szabja meg, nem a fejlesztés ára. Két azonos pénzből épített rendszer között háromszoros eltérés is lehet, az integrációk számától, a szabályozási kitettségtől és a támogatási forgalomtól függően.

Milyen karbantartási költségeket felejtenek ki a csapatok? A függőségek frissítését, a külső API-k kivezetését olyan határidőkkel, amelyeket nem te választottál, a tanúsítványok és domainek megújítását, a felügyeleti riasztások mögötti emberi rendelkezésre állást, a tudásátadást, amikor elmennek az emberek, valamint az adatnövekedés hatását a tárolási költségre és a lekérdezések sebességére.

Átalánydíjat válasszak, vagy alkalmanként fizessek? A meghatározott óraszámú átalánydíj kiszámítható mennyiséghez való, és rendelkezésre állást vásárol, amiért többnyire fizetsz. Az idő és anyag alapú elszámolás a keveset változó rendszerekhez illik, de a válaszidő a szolgáltató egyéb kötelezettségeitől függ. Bármelyiket választod, még azelőtt határozd meg, mi számít karbantartásnak és mi új funkciónak, hogy szükséged lenne rá.