Egy idejemúlt és rossz metrika a szoftverfejlesztésről

Egy idejemúlt és rossz metrika a szoftverfejlesztésről

A Function Point egy szoftver metrika annak a mérésére, hogy a szoftverünk mekkora. 1979-ben Alan Albrecht találta ki az IBM-nél. Az FP az ISO által elismert 5 módszer egyike a szoftver helyes méretezésének.

További részleteket itt lehet olvasni: How to Determine Your Software Application Size Using Function Point Analysis

Azon kevés szerencsés – vagy kevésbé szerencsés – informatikus közé tartozok, akinek van szerencsére testközelből látni az FPA-t. Talán nem véletlenül ismerik kevesen.

Három nagyon súlyos problémát látok az FPA-vel:

1) Tanácsadók

Bár az FP a marketing bullshit szerint könnyen, egyszerűen számítható, de azért mégsem annyira könnyen, hogy az informatikusok ezzel foglalkozzanak. Ezért tapasztalt FPA szakértőket kell bevonni, akik majd jó pénzért számítják a pontokat. És ahogyan az lenni szokott, az egyszerű elgondolásra egy egész iparág épült: könyvek, tanfolyamok, minősítések, fórumok és konferenciák. Pont ahogy az ISO, CMMI, 6 Sigma és minden más esetben.

Amikor pedig ezen emberek megélhetése múlik a módszertanon, akkor bárkit meggyőznek arról, hogy anélkül nem lehet élni.

Márpedig pont a nagy és komoly cégek azok, akik nem ISO minősítettek.

(És pont a héten beszélgettünk a CMMI-ról valakivel. Azon gondolkodott hangosan, milyen lenne egy CMMI Level 5 cégnél dolgozni. Én ezen már túl vagyok, nem ajánlom senkinek.)

2) Hibás alkalmazás

Az FP alapgondolatát helyesnek tartom és egyetértek vele. Ami rosszá teszi, hogy megpróbálják kalapácsnak használni és mindent szögnek néznek.

Íróasztalon, elméletben tényleg igaz az, hogy a szoftver mérete jól mérhető a funkcionális pontokkal, ezáltal a szoftverfejlesztési projekt is mérhető az FP-k számával. Azonban a 21. században a szoftverfejlesztés már inkább változáskérelmeket jelent, amikor nem sok-sok új funkciót adunk hozzá a rendszerhez, hanem csak keveset, de azokat beleintegráljuk a meglévő rendszerbe és hozzáigazítjuk a többit. A fejlesztés célja is eltolódott a mennyiségi fejlesztés (új funkciók mennyisége) helyett az ügyfél érték felé (használhatóság, stabilitás, rendszer egységességének megőrzése).

Konkrét példa: van egy fejlesztési projekt. A fejlesztés során bevezetünk egy fogalmat egy meglévő szoftverben, az új fogalomhoz kapcsolódóan beleteszünk 3 új funkciót és hozzányúlunk további 30-hoz, hogy a szoftver működése konzisztens legyen.
Az FPA szerint az értékes munka csak 3 funkció volt, és feleslegesen fecséreltük az időnket a módosításokkal.

3) És ha megvan a FPA, mire megyek vele?

Mire is megy vele a menedzsment, ha minden fejlesztési projektről kap egy részletes és korrekt FPA riportot? Semmivel sem lesznek előrébb, mintha nem lenne FPA riport.

Az FPA nem fedi le helyesen a munkát, nem mutatja meg a fejlesztéssel termelt üzleti értéket, nem mutatja meg a fejlesztés minőségét. Összességében tehát nem tudjuk meg, hogy a fejlesztés jól vagy rosszul sikerült-e.

Mit tudunk meg akkor? Semmit. Lesz +1 viszonyszámunk. De viszonyszámunk FPA nélkül is lenne, ott van a költségelemzés és a ráfordított munka.

Viszont jól el lehet tölteni az időt FP-k számolgatásával, nagy zsét adni a tanácsadóknak, és színes prezentációkat készíteni. A munka tökéletes illúzióját keltjük.

Aki mérni akarja a szoftverfejlesztés minőségét, az inkább az eredményességet, ROI-t és ügyfél-elégedettséget mérjen.