Wprowadzenie

Bardzo czę­sto spo­ty­kam się z meto­da­mi wymia­ro­wa­nia opro­gra­mo­wa­nia, czy­li mówiąc ludz­kim języ­kiem: oce­ny pra­co­chłon­no­ści jego wytwo­rze­nia. Typowym argu­men­tem za sto­so­wa­niem tych metod jest potrze­ba pla­no­wa­nia. Nie raz spo­ty­kam się z porów­na­nia­mi do pomia­ru powierzch­ni np. w budow­nic­twie (cytat celo­wo ze stro­ny sto­sow­ne­go stowarzyszenia):

Wymiarowanie opro­gra­mo­wa­nia, ma podob­ne zna­cze­nie, co wymia­ro­wa­nie w innych dzie­dzi­nach inży­nie­rii. Określa wiel­kość, pozwa­la na porów­ny­wa­nie róż­nych przed­się­wzięć, sza­co­wa­nie kosz­tów wytwa­rza­nia i lep­sze pla­no­wa­nie. Punkty funk­cyj­ne ? naj­bar­dziej popu­lar­na i pro­mo­wa­na przez spe­cja­li­stów jed­nost­ka wiel­ko­ści opro­gra­mo­wa­nia, to przy­kła­do­wo odpo­wied­nik metrów kwa­dra­to­wych w budow­nic­twie. Wyobraźmy sobie tę bran­żę, przy zało­że­niu, że nie posłu­gu­je­my się żad­ną jed­nost­ką powierzch­ni. Inwestycje były­by wyce­nia­ne, a ich reali­za­cja pla­no­wa­na nawet bez pró­by osza­co­wa­nia np. powierzch­ni użyt­ko­wej? Wydaje się to absur­dem, a jed­nak w takiej rze­czy­wi­sto­ści funk­cjo­nu­je rynek opro­gra­mo­wa­nia i nie­ste­ty ‑zwią­za­ny z nim świat zamó­wień publicznych.Nie jest to tyl­ko pro­blem pol­ski, jest to bolącz­ka całej bran­ży. Nic dziw­ne­go, że aż 63% pro­jek­tów koń­czy się poraż­ką, a pla­no­wa­ny czas prze­kra­cza­ny śred­nio o 80%, zaś kosz­ty śred­nio o 55%. Na świe­cie stra­ty będą­ce skut­kiem tych nie­po­wo­dzeń liczo­ne są w set­kach miliar­dów dola­rów rocz­nie. Walkę z tym pro­ble­mem pod­ję­to już wie­le lat temu. Zamawiane opro­gra­mo­wa­nie, wszę­dzie tam gdzie decy­den­ci są świa­do­mi zagro­żeń, jest mie­rzo­ne. A coraz wię­cej admi­ni­stra­cji pań­stwo­wych jako nor­mę, trak­tu­ją obo­wią­zek wymia­ro­wa­nia opro­gra­mo­wa­nia przed jego zamó­wie­niem. Dobre prak­ty­ki i narzę­dzia będą­ce wyni­kiem tej bata­lii są na wycią­gnię­cie ręki. 

(pier­wot­ne źró­dło jest nie­do­stęp­ne, porów­naj inny mate­riał: https://​www​.com​pu​ter​world​.pl/​n​e​w​s​/​S​k​u​t​e​c​z​n​e​-​m​e​t​o​d​y​-​w​y​m​i​a​r​o​w​a​n​i​a​-​p​r​o​j​e​k​t​o​w​-​I​T​,​4​0​8​5​9​3​.​h​tml)

Ogólnie teza jakiej bro­nią zwo­len­ni­cy tego typu metod brzmi:

moż­li­we jest osza­co­wa­nie pra­co­chłon­no­ści (kosz­tu) wytwo­rze­nia opro­gra­mo­wa­nia wyłącz­nie na bazie wie­dzy o tym, do cze­go ma ono służyć

Innymi sło­wy uwa­ża­my, że na bazie wyma­gań funk­cjo­nal­nych (z regu­ły mowa o przy­pad­kach uży­cia) moż­na osza­co­wać zło­żo­ność apli­ka­cji. Niestety w swo­jej wie­lo­let­niej karie­rze nigdy nie spo­tka­łem się z przy­pad­kiem by wyce­na taka choć zbli­ży­ła się do póź­niej­szych fak­tycz­nych kosz­tów wytwo­rze­nia apli­ka­cji (rzad­kie przy­pad­ko­we zbież­no­ści nie są dowo­dem sku­tecz­no­ści meto­dy). Raczej spo­ty­kam się dość czę­sto z czymś co opi­sa­łem w 2013 roku (tych wycen, zgod­nie z SIWZ, doko­na­no na bazie meto­dy punk­tów funkcyjnych):

Co mnie zasta­na­wia? Przede wszyst­kim to, że ?pro­fe­sjo­nal­ne? fir­my z ogrom­nym (jak twier­dzą na swo­ich stro­nach) doświad­cze­niem, pre­zen­tu­ją ofer­ty opra­co­wa­ne na bazie tej samej doku­men­ta­cji (w koń­cu to prze­targ), a roz­rzut cen tych ofert jest czte­ro­krot­ny!!! ?(Żeliński, 2013)?

Takich przy­pad­ków jest wie­le, i moim zda­niem prak­tycz­nie oba­la­ją tezę o sku­tecz­no­ści tego typu metod (meto­da punk­tów funk­cyj­nych i pokrewne).

Punkty funkcyjne

Jedną z popu­lar­niej­szych i czę­sto pro­mo­wa­nych metod jest ana­li­za punk­tów funk­cyj­nych pro­mo­wa­na przez International Function Point Users Group (IFPUG). W tej rodzi­ny nale­ży mię­dzy inny­mi COSMIC. Metoda ta bazu­je na dość pro­stych założeniach:

The prin­ci­ples for measu­ring the COSMIC func­tio­nal size of a pie­ce of softwareThe COSMIC method measu­res a size as seen by the ?func­tio­nal users? of the pie­ce of softwa­re to be measu­red, i.e. the sen­ders and/or inten­ded reci­pients of the data that must enter or exit from the softwa­re, respectively.The method uses a model of softwa­re, known as the ?COSMIC Generic Software Model?, which is based on fun­da­men­tal softwa­re engi­ne­ering prin­ci­ples, namely:Functional user requ­ire­ments of a pie­ce of softwa­re can be ana­ly­zed into uni­que func­tio­nal pro­ces­ses, which con­sist of sub-pro­ces­ses. A sub-pro­cess may be either a data move­ment or a data manipulation;Each func­tio­nal pro­cess is trig­ge­red by an ?Entry? data move­ment from a func­tio­nal user which informs the func­tio­nal pro­cess that the func­tio­nal user has iden­ti­fied an event that the softwa­re must respond to;A data move­ment moves a sin­gle data gro­up of attri­bu­tes descri­bing a sin­gle ?object of inte­rest?, whe­re the lat­ter is a ?thing? of inte­rest to a func­tio­nal user;There are four types of data move­ment sub-pro­ces­ses. An ?Entry? moves a data gro­up into the softwa­re from a func­tio­nal user and an ?Exit? moves a data gro­up out. ?Writes? and ?Reads? move a data gro­up to and from per­si­stent sto­ra­ge, respectively.[…]

As an appro­xi­ma­tion for measu­re­ment pur­po­ses (and in light of the appli­ca­bi­li­ty of the method, descri­bed abo­ve), data mani­pu­la­tion sub-pro­ces­ses are not sepa­ra­te­ly measured.

The size of a pie­ce of softwa­re is then defi­ned as the total num­ber of data move­ments (Entries, Exits, Reads and Writes) sum­med over all func­tio­nal pro­ces­ses of the pie­ce of softwa­re. Each data move­ment is coun­ted as one ?COSMIC Function Point? (?CFP?). The size of a func­tio­nal pro­cess, and hen­ce the size of a pie­ce of softwa­re, can be a mini­mum of 2 CFP, with no upper limit. (The COSMIC Software Sizing Methodology. (n.d.). Retrieved May 9, 2019, from COSMIC websi­te: http://​cosmic​-sizing​.org/​c​o​s​m​i​c​-​f​sm/)

(zobacz tak­że opis wdro­żo­nej wer­sji udo­stęp­nio­ny przez ZUS).

Model opi­su­ją­cy fun­da­men­tal­ne zało­że­nia tej meto­dy wyglą­da tak:

Generalnie na eta­pie ana­li­zy, bazu­ją­cej na spe­cy­fi­ka­cji wyma­gań funk­cjo­nal­nych, two­rzo­na jest lista inte­rak­cji z apli­ka­cją Entry/Exit (czy­li tego to co widzi i jest w sta­nie opi­sać przy­szły użyt­kow­nik – lewa stro­na powyż­sze­go mode­lu) i lista ope­ra­cji Write/Read (zapis i odczyt danych, pra­wa stro­na mode­lu). Komponent, któ­ry nazwa­no tu Software, to pewien rodzaj czar­nej skrzyn­ki. Metoda ta po pierw­sze wyma­ga spro­wa­dze­nia wyma­gań do pozio­mu kurio­zal­nie roz­drob­nio­nych przy­pad­ków uży­cia (co opi­sa­łem nie­daw­no w arty­ku­le o pew­nej meto­dzie trans­for­ma­cji pro­ce­su biz­ne­so­we­go na przy­pad­ki uży­cia), po dru­gie zupeł­nie abs­tra­hu­je od wewnętrz­nej zło­żo­no­ści (w naj­now­szej wer­sji tej meto­dy przyj­mu­je się wagi zło­żo­no­ści, nie­ste­ty są one uzna­nio­we). Metoda powsta­ła ponad 30 lat temu, w cza­sach gdy inży­nie­ria opro­gra­mo­wa­nia spro­wa­dza­ła się do maksymy:

dane + funk­cje = oprogramowanie

To jest nie­ste­ty jed­nak pre­hi­sto­ria inży­nie­rii opro­gra­mo­wa­nia. Owszem powsta­je jesz­cze opro­gra­mo­wa­nie w myśl tej mak­sy­my (głów­nie sys­te­mu zarzą­dza­nia wie­dzą), ale nawet śred­nio zło­żo­ne biz­ne­so­we apli­ka­cje, two­rzo­ne jako otwar­te archi­tek­tu­ry obiek­to­we, nie­ste­ty nie pasu­ją do tego ​„wzor­ca”. porów­naj­my powyż­szy model z tym:

Powyżej dość typo­wa obiek­to­wa archi­tek­tu­ra apli­ka­cji. Kilka wniosków:

• przy­pa­dek uży­cia nie jest ​„nisko­po­zio­mo­wą funk­cją sys­te­mu”, takie ich defi­nio­wa­nie (nie­zgod­ne z UML) pro­wa­dzi do mon­stru­al­nej zło­żo­no­ści i pra­co­chłon­no­ści już na eta­pie ana­li­zy wymagań,
• ope­ra­cje zapi­su i odczy­tu danych (repo­zy­to­ria, obiek­ty skraj­nie po pra­wej) w żaden spo­sób nie odzwier­cie­dla­ją zło­żo­no­ści apli­ka­cji, ta ​„tkwi” w kom­po­nen­tach wewnętrz­nych a te nie są zna­ne na tym etapie,
• wie­le zło­żo­nych ele­men­tów kodu – samo­dziel­ne usłu­gi wewnętrz­ne – nie ma bez­po­śred­nio nic wspól­ne­go ani z zapi­sem danych ani z inte­rak­cja z samą aplikacją,
• uzna­nie, że moż­na osza­co­wać zło­żo­ność wytwo­rze­nia sys­te­mu tyl­ko na bazie pla­no­wa­nych funk­cjo­nal­no­ści i mode­lu danych moim zda­niem jest nie obrony.

Powyższy model poka­zu­je, że klu­czo­wa zło­żo­ność apli­ka­cji tkwi w czę­ści nazwa­nej w COSMIC ​„softwa­re”, cał­ko­wi­cie pomię­tej w toku pro­wa­dze­nia szacowania.

Model COSMIC (i podob­ne meto­dy) cał­ko­wi­cie abs­tra­hu­je od tego, że apli­ka­cja mogła by powstać na bazie obiek­to­we­go para­dyg­ma­tu i wzor­ców SOLID (w szcze­gól­no­ści otwar­tość na roz­sze­rze­nia przy bra­ku wpro­wa­dza­nia zmian czy­li tak zwa­ne open clo­se prin­ci­ple). Uznanie, że każ­de opro­gra­mo­wa­nie moż­na spro­wa­dzić do pozio­mu ope­ra­cji zapi­su i odczy­tu z logi­ką takich ope­ra­cji umiesz­czo­ną w odwo­ła­niach do bazy danych, cofa nas o 40 lat, do cza­sów metod struk­tu­ral­nych (w tych cza­sach powsta­ła ta meto­da COSMIC). Stowarzyszenie pro­mu­ją­ce meto­dę COSMIC pisze: „… 63% pro­jek­tów koń­czy się poraż­ką, a pla­no­wa­ny czas prze­kra­cza­ny śred­nio o 80%, zaś kosz­ty śred­nio o 55%. Na świe­cie stra­ty będą­ce skut­kiem tych nie­po­wo­dzeń liczo­ne są w set­kach miliar­dów dola­rów rocz­nie …”, doda­je, że od 40 lat te sta­ty­sty­ki się nie zmie­nia­ją a meto­da ta ma porów­ny­wal­ny czas ist­nie­nia, wiec jak na tym tle oce­nić jej sta­ły roz­wój i domnie­ma­ną skuteczność?

Wielokrotnie widzia­łem, jak budżet i har­mo­no­gram pro­jek­tu wyli­czo­ny na bazie meto­dy punk­tów funk­cyj­nych, był ​„nisz­czo­ny” jed­nym tyl­ko fak­tem roz­po­czę­cia doku­men­to­wa­nia i imple­men­ta­cji raba­to­wa­nia w ​„przy­pad­ku uży­cia” Wystawianie Faktur Sprzedaży. Klasyka nie­ja­ko oba­la­ją­ca sku­tecz­ność tej meto­dy to sys­tem sco­rin­go­wy, któ­re­go prak­tycz­nie cała zło­żo­ność leży poza ope­ra­cja­mi wejścia/wyjścia, a tego rodza­ju pro­ble­mów w tak zwa­nych sys­te­mach biz­ne­so­wych jest bar­dzo wie­le, zary­zy­ku­je nawet tezę, że to typo­we pro­ble­my w obec­nych sys­te­mach wspo­ma­ga­nia zarzą­dza­nia. Metody tego typu, nie raz opar­ta na zbie­ra­nym doświad­cze­niu, są nadal popu­arc­ne .

Jak więc wymia­ro­wać opro­gra­mo­wa­nie? Tu zno­wu pozo­sta­je uczyć się od naj­star­szej dzie­dzi­ny inży­nie­rii czy­li budow­nic­twa: budow­le moż­na wyce­nić tyl­ko na pod­sta­wie pro­jek­tu całej kon­struk­cji (dla apli­ka­cji jest to jej wewnętrz­na archi­tek­tu­ra i logi­ka dzia­ła­nia), na bazie same­go pomy­słu na wiel­ki dom nie da się wyli­czyć ile będzie kosz­to­wa­ło jego posta­wie­nie. Od wie­lu lat mam do czy­nie­nia z ofer­ta­mi skła­da­ny­mi w odpo­wie­dzi na ten sam doku­ment opi­su­ją­cy wyma­ga­nia, roz­rzut wycen (bywa, że o rząd wiel­ko­ści) oba­la każ­dą teo­rię mówią­ca, że jest moż­li­we sen­sow­ne sza­co­wa­nie na tym (przed-pro­jek­to­wym) eta­pie, a wiem, że wie­le z tych wycen jest przy­go­to­wy­wa­nych wła­śnie na bazie metod opar­tych na punk­tach funkcyjnych.

Jedynym sku­tecz­nym spo­so­bem jaki znam i jaki widu­ję w prak­ty­ce, jest wyce­na na bazie pro­jek­tu zawie­ra­ją­ce­go model dzie­dzi­ny sys­te­mu z dokład­nym mode­lem dzia­ła­nia (logi­ki biz­ne­so­wej). Dużo dokład­niej­sze są wyce­ny, doko­ny­wa­ne rela­tyw­nie niskim nakła­dem pra­cy, przez doświad­czo­nych archi­tek­tów opro­gra­mo­wa­nia na bazie co naj­mniej wstęp­nych pro­jek­tów. Wycena na bazie ​„czar­nej skrzyn­ki”, jaką są przy­pad­ki uży­cia ​„dekla­ro­wa­ne” przez zama­wia­ją­ce­go, to raczej wró­że­nie z fusów.

[uzu­peł­nie­nie] Pewną odmia­ną powyż­szej meto­dy (COSMIC) jest meto­da punk­tów funk­cyj­nych IFPUG (z International Function Point Users Group). Oparta jest dekla­ro­wa­nych funk­cjo­nal­no­ściach i zbie­ra­nych danych histo­rycz­nych ze zre­ali­zo­wa­nych pro­jek­tów. Pomysł pole­ga na uzna­niu, że kosz­ty imple­men­ta­cji ​„podob­nych funk­cji sys­te­mu” są tak­że podobne. 

Niestety to zało­że­nie nie znaj­du­je potwier­dze­nia w prak­ty­ce a twór­cy meto­dy sami przy­zna­ją, że jej sku­tecz­ność jest niska .

Powyższe to wstęp do pew­ne­go ofi­cjal­ne­go doku­men­tu. Konia z rzę­dem temu kto okre­śli poję­cie funk­cjo­nal­no­ści biz­ne­so­wej usłu­gi apli­ka­cji i jej licz­bę jed­no­stek, nie widząc jak będzie reali­zo­wa­na. Prosty przy­kład: apli­ka­cja dla Biblioteki (patrz: Inżynieria opro­gra­mo­wa­nia z uży­ciem narzę­dzia CASE ? pro­jekt badaw­czy) ma mieć funk­cjo­nal­ność «wypo­ży­cze­nie książ­ki» i «zwrot książ­ki», rzecz w tym, że naj­lep­sza spraw­dzo­na imple­men­ta­cja to nie będą ​„dwie funk­cje” tyl­ko jed­na for­mat­ka ekra­no­wa Karta Wypożyczenia a zwrot książ­ki będzie reali­zo­wa­ny poprzez wpi­sa­nie daty zwro­tu na wysta­wio­nej wcze­śniej Karcie Wypożyczenia. W tym momen­cie wymia­ro­wa­nie IFPUG (COSMIC tak­że) jest po pro­stu fun­ta kła­ków war­te: będzie potęż­nie zawy­żo­ne, a deve­lo­per – pod dyk­tan­do takiej wyce­ny – wyko­na bar­dzo złą i kosz­tow­ną imple­men­ta­cję. Innym powo­dem niskiej wia­ry­god­no­ści tego typu metod jest to, że na eta­pie w któ­rym zna­my przy­pad­ki uży­cia a nie zna­my ich imple­men­ta­cji nie mam pod­staw do oce­ny zło­żo­no­ści bo nie wie­my ile będzie sce­na­riu­szy dla każ­de­go przy­pad­ku uży­cia a może ich być wię­cej niż jeden (patrz Use Case 2.0). Po trze­cie jakość mode­lu przy­pad­ków uży­cia też ma ogrom­ny wpływ na tak­że wyce­nę (patrz Przypadki uży­cia i ich deta­le).

Podsumowanie

Metody wyce­ny bazu­ją­ce na sta­ty­sty­kach pocho­dzą­cych ze zre­ali­zo­wa­nych pro­jek­tów są opar­te na zało­że­niu, że wyce­nia­ny pro­jekt będzie reali­zo­wa­ny tymi samy­mi lub ana­lo­gicz­ny­mi meto­da­mi co samo z sie­bie jest zaprze­cze­niem postę­pu tech­nicz­ne­go i roz­wo­ju metod inży­nie­rii opro­gra­mo­wa­nia. Praktyka poka­zu­je, że wyce­ny tymi meto­da­mi są prak­tycz­nie pra­wie zawsze zawy­żo­ne a obsza­ry nowa­tor­skie moc­no nie­do­sza­co­wa­ne lub prze­sza­co­wa­ne (bo nowa funk­cjo­nal­ność z zasa­dy nie ma histo­rii). W efek­cie moż­na pod­su­mo­wać to tak: meto­dy sta­ty­stycz­ne wymia­ro­wa­nia, opar­te na przy­pad­kach uży­cia lub funk­cjo­nal­no­ściach, to meto­dy opar­te na pre­dyk­cji histo­rycz­nych danych pro­jek­to­wych, gdzie mate­ria­łem wej­ścio­wym jest model czar­nej skrzyn­ki. Jeżeli do tego doda­my infor­ma­cję o jako­ści reali­za­cji pro­jek­tów infor­ma­tycz­nych publi­ko­wa­ne cyklicz­nie przez Standish Group:

To wnio­sek jaki się nasu­wa to: sto­so­wa­nie metod sta­ty­stycz­nych, zawy­ża­ją­cych wyce­ny, beto­nu­je kata­stro­fal­ny stan opi­sa­ny w tych rapor­tach. Alternatywą jest pro­ces MDA/SPEM, któ­ry zakła­da, że wyce­na będzie doko­ny­wa­na dopie­ro po opra­co­wa­niu co naj­mniej wstęp­ne­go pro­jek­tu imple­men­ta­cji usług apli­ka­cji (przy­pad­ki uży­cia), co nie tyl­ko uwia­ry­god­ni wyce­nę ale tak­że roz­wią­że wie­le wąt­pli­wo­ści na tym wcze­snym etapie. 

Źródła