Wymiarowanie oprogramowania

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).

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:

źr. http://file.scirp.org/Html/3-9301348_17476.htm
?(?Design of a Performance Measurement Framework for Cloud Computing,? n.d.)?

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:

Obiektowy model dziedziny Zasada SOLID
Obiektowy model archi­tek­tu­ry apli­ka­cji na bazie wzor­ca BCE, Zasada SOLID (opr. Jarosław Żeliński)

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 .

Podręcznik Stosowania meto­dy Punktów Funkcyjnych IFPUG w Agencji Restrukturyzacji i Modernizacji Rolnictwa (2018)

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).

Generalnie moż­na pod­su­mo­wać to tak: meto­dy 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. 

(arty­kuł uzu­peł­nio­ny w 2021 r.)

Źródła

Czarnacka-Chrobot, B. (2009). WYMIAROWANIE FUNKCJONALNE PRZEDSIĘWZIĘĆ ROZWOJU SYSTEMÓW OPROGRAMOWANIA WSPOMAGAJĄCYCH ZARZĄDZANIE NA BAZIE UOGÓLNIONYCH DANYCH HISTORYCZNYCH. 13.
Pospieszny, P., Czarnacka-Chrobot, B., & Kobyliński, A. (2015). Application of Function Points and Data Mining Techniques for Software Estimation – A Combined Approach. In A. Kobyliński, B. Czarnacka-Chrobot, & J. Świerczek (Eds.), Software Measurement (Vol. 230, pp. 96 – 113). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 24285-9_7
Bautista, L., Abran, A., & April, A. (2012). Design of a Performance Measurement Framework for Cloud Computing. 2012. https://​doi​.org/​1​0​.​4​2​3​6​/​j​s​e​a​.​2​0​1​2​.​5​2​011

Przetarg czyli wycena projektu…

teczki, akta, papiery

O prze­tar­gach napi­sa­no tak wie­le kry­tycz­nych tek­stów, więc po co ten? Nie będę się tu pastwił nad nimi. Zastanawia mnie co inne­go, i tu mała krytyka…

W pra­sie poja­wi­ły się donie­sie­nia o roz­strzy­ga­nym prze­tar­gu ogło­szo­nym przez [[ARiMR]]:

Asseco Poland za swo­je pra­ce zapro­po­no­wa­ło 40,65 mln zł, a Sygnity 43,98 mln zł. W prze­tar­gu star­to­wa­ły też: kon­sor­cjum ze spół­ką zależ­ną Asseco – ZETO Łódź (29,36 mln zł) i kon­sor­cjum z Infovide-Matrix (31,75 mln zł). Wybrana poprzed­nio [[ofer­ta kon­sor­cjum IT Works i Almaviva]] opie­wa­ła na 9,92 mln zł. Przetarg reali­zo­wa­ny był według pro­ce­du­ry ogra­ni­czo­nej przy­spie­szo­nej. Kryterium oce­ny ofert w tym postę­po­wa­niu była cena. (Oferta Comarchu naj­ko­rzyst­niej­sza w prze­tar­gu ARiMR. wnp​.pl | Informatyka. Informatyka dla prze­my­słu.).

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 czterokrotny!!!

Nie może to być (tak sądzę) kwe­stią zakre­su pro­jek­tu, bo ten jest opi­sa­ny w SIWZ (Specyfikacja Istotnych Warunków Zamówienia, ta zawie­ra Opis Przedmiotu Zamówienia). Czy na pew­no? Wstępnie wyda­je mi się, że są dwie moż­li­we przy­czy­ny takie­go roz­rzu­tu: sła­by OPZ albo róż­ni­ce w spo­so­bie i meto­dach pra­cy ofe­ren­tów, tu wyce­ny i metod wytwa­rza­nia. Popatrzmy na kry­te­ria oce­ny (źr. str. WWW AMRiR):

kry­te­ria udzie­le­nia zamó­wie­nia: Cena rocz­ne­go utrzy­ma­nia ? 55%. Cena 1 Punktu Funkcyjnego – 35%. Gwarancja ? 10% gwa­ran­cja na opro­gra­mo­wa­nie, funk­cjo­nu­ją­ce w dniu zakoń­cze­nia obo­wią­zy­wa­nia umo­wy, roz­po­czy­na­ją­ca się od dnia zakoń­cze­nia umo­wy. Każdy mie­siąc trwa­nia gwa­ran­cji + 2,5 pkt., mak­sy­mal­nie 10 pkt.

Jednym ze skład­ni­ków ceny jest tak zwa­ny punkt funk­cyj­ny”. Cóż to jest? To jed­na z popu­lar­niej­szych metod wyce­ny. Jak to dzia­ła? WIKI:

Podstawowym zało­że­niem meto­dy punk­tów funk­cyj­nych jest podzie­le­nie opro­gra­mo­wa­nia na pięć składowych.

  1. Zewnętrzne typy wej­ścia to meto­dy doko­ny­wa­nia zmian w wewnętrz­nych danych systemu.
  2. Zewnętrzne typy wyj­ścia to meto­dy repre­zen­ta­cji danych prze­cho­wy­wa­nych przez sys­tem. Przykładem są wydru­ki kom­pu­te­ro­we. Dane wyświe­tla­ne na ekra­nie nie nale­żą do tej kate­go­rii, są kwa­li­fi­ko­wa­ne jako opi­sa­ne poni­żej zewnętrz­ne typy zapytań.
  3. Logiczne wewnętrz­ne typy pli­ków to pli­ki uży­wa­ne wewnętrz­nie przez sys­tem. We współ­cze­snej infor­ma­ty­ce poję­cie pli­ku zmie­ni­ło swo­je zna­cze­nie. Składową tą może­my inter­pre­to­wać jako zbiór danych opi­su­ją­cych obiek­ty dane­go typu, na przy­kład tabe­lę w rela­cyj­nej bazie danych.
  4. Zewnętrzne typy inter­fej­sów pli­ków to meto­dy wymia­ny danych mię­dzy inny­mi sys­te­ma­mi infor­ma­tycz­ny­mi. Przykładem może być inter­fejs umoż­li­wia­ją­cy pobie­ra­nie danych z apli­ka­cji inter­ne­to­wej w for­ma­cie JSON lub pli­ki współ­dzie­lo­ne mię­dzy róż­ny­mi aplikacjami.
  5. Zewnętrzne typy zapy­tań to meto­dy odczy­tu danych z sys­te­mu nie powo­du­ją­ce ich mody­fi­ka­cji. Przykładem jest zapy­ta­nie SELECT z języ­ka SQL.

Wady meto­dy wska­za­ne w jej opi­sie w WIKI:

  • Mimo że meto­da jest naj­bar­dziej dopra­co­wa­ną i naj­po­pu­lar­niej­szą meto­dą sza­co­wa­nia war­to­ści funk­cji oce­nia­ne­go pro­gra­mu, to nie pozo­sta­je ona bez wad. Jedną z nich, wska­za­ną już przez Albrechta, jest subiek­tyw­ność war­to­ścio­wa­nia zło­żo­no­ści typu jako niskiej, śred­niej lub dużej. Istotność tej wady obec­nie jest niwe­lo­wa­na opra­co­wa­ną przez IFPUG meto­dy­ką oce­ny zło­żo­no­ści (file type complexity).
  • Kolejnym pro­ble­mem jest cza­so­chłon­ność (koszt) pro­ce­su wyli­cza­nia punk­tów funk­cyj­nych, gdyż z powo­du nie­zna­nej dokład­no­ści takich wyli­czeń nie jest sto­so­wa­na auto­ma­ty­za­cja. tego pro­ce­su , ponie­waż nie­zna­na jest w takim przy­pad­ku – nie wia­do­mo czy jest duża czy mała.
  • Innym man­ka­men­tem jest to, że wyni­ki meto­dy w przy­pad­ku małych sys­te­mów mogą być mało dokładne.
  • Metoda punk­tów funk­cyj­nych nie bie­rze rów­nież pod uwa­gę zło­żo­no­ści imple­men­ta­cji algo­ryt­mów dzia­ła­ją­cych wewnątrz systemu.

(Punkt funk­cyj­ny ? Wikipedia, wol­na ency­klo­pe­dia.)

Po pierw­sze meto­da powsta­ła ponad 30 lat temu, gdy stan­dar­do­wą meto­dy­ką two­rze­nia opro­gra­mo­wa­nia były meto­dy struk­tu­ral­ne (bazu­ją na odse­pa­ro­wa­nej liście funk­cji prze­twa­rza­ją­cych dane prze­cho­wy­wa­ne w odręb­nej bazie danych w mode­lu rela­cyj­nym stad przy­kład z SELECT’em w języ­ku SQL). Metoda, choć archa­icz­na, jest nadal roz­wi­ja­na i dość powszech­nie sto­so­wa­na. Dlaczego? Moim zda­niem dla­te­go, że bazu­je na tak zwa­nej per­spek­ty­wie użyt­kow­ni­ka”: Granice [zakre­su ana­li­zy] powi­nien okre­ślać użyt­kow­nik w opar­ciu o swój punkt widze­nia i zapo­trze­bo­wa­nie. Ograniczenia tech­no­lo­gicz­ne nie powin­ny być bra­ne pod uwa­gę pod­czas okre­śla­nia gra­nic mię­dzy współ­pra­cu­ją­cy­mi sys­te­ma­mi. Należy kie­ro­wać się przy tym ich funk­cjo­nal­no­ścią. (WIKI). Jest to łatwa i pro­sta meto­da, nie wyma­ga zbyt dużych kom­pe­ten­cji (a pamię­taj­my, że duże fir­my czę­sto cechu­je dość duża rota­cja pra­cow­ni­ków co nie sprzy­ja gro­ma­dze­niu kompetencji).

Powszechnie przy­ję­tą prak­ty­ką jest wyce­na wyko­na­nia dedy­ko­wa­ne­go opro­gra­mo­wa­nia na bazie opi­su wyma­gań naj­czę­ściej w posta­ci wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych”. Jednak tak opi­sa­ne wyma­ga­nia to jedy­nie opis tego jaki efekt chce osią­gnąć zama­wia­ją­cy, nic nie mówią o tym jak” on zosta­nie osią­gnię­ty. Metod i narzę­dzi wytwa­rza­nia opro­gra­mo­wa­nia jest wie­le, kom­pe­ten­cje wyko­naw­ców tak­że bar­dzo róż­ne. W efek­cie, moim zda­niem, oce­na ofert na bazie takich spe­cy­fi­ka­cji to lote­ria. (moim zda­niem meto­dy wyce­ny opar­te na przy­pad­kach uży­cia i obiek­to­wych wzor­cach pro­jek­to­wych ich imple­men­ta­cji są znacz­nie bar­dziej wia­ry­god­ne, opis przy innej okazji).

Drugi ele­ment to oce­na ofe­ren­tów. Bardzo czę­sto zama­wia­ją­cy narzu­ca ogrom­ne wyma­ga­nia finan­so­we na dostaw­ców: wyso­kie wadium, wyso­kie wyma­ga­nia na obro­ty rocz­ne itp. Do tego lata doświad­czeń itp. Popatrzmy na pro­fe­sjo­na­lizm inży­nie­rii i umie­jęt­no­ści o podob­nym cha­rak­te­rze: co świad­czy o mecha­ni­ku samo­cho­do­wym? To ile lat napra­wia samo­cho­dy czy to jakie i jaki­mi meto­da­mi? Czy to, że zespół pro­gra­mi­stów to ludzie od 15 lat piszą­cy opro­gra­mo­wa­nie w Pascalu, pozwa­la uznać ich za bar­dzo dobrych spe­cja­li­stów? W czym?

Dzisiaj na ryn­ku inży­nie­rii opro­gra­mo­wa­nia kró­lu­ją meto­dy i narzę­dzia obiek­to­we (co by to nie mia­ło zna­czyć) a nie struk­tu­ral­ne, uzna­ne daw­no za nie­efek­tyw­ne w two­rze­niu opro­gra­mo­wa­nia o cha­rak­te­rze biz­ne­so­wym (o innym się nie wypo­wia­dam ;)). Metody obiek­to­we są efek­tyw­niej­sze zarów­no na eta­pie ana­li­zy i pro­jek­to­wa­nia jak i na eta­pie imple­men­ta­cji, ale wyma­ga­ją zupeł­nie nowej wie­dzy w sto­sun­ku do metod struk­tu­ral­nych (nie­ste­ty nasze uczel­nie uczą głów­nie metod strukturalnych).

Czy powyż­szy roz­rzut cen to efekt róż­nic w tech­no­lo­gii sto­so­wa­nej przez ofe­ren­tów czy ich kom­pe­ten­cji? Osobiście sta­wiam głow­nie na nie­sku­tecz­ność meto­dy punk­tów funk­cyj­nych i wła­snie sła­be kompetencje.

Trudno o inne wnio­ski. Za mało danych zawie­ra­ją infor­ma­cje z roz­strzy­ga­nych prze­tar­gów, a nie­ste­ty ofer­ty nie są publi­ko­wa­ne (nie rozu­miem dla­cze­go i nie ja jeden.…). Argument, że ofer­ta jest pouf­na” do mnie nie prze­ma­wia, bo Urzędy nie mają chro­nio­ne­go know-how a więc logi­ka nowe­go sys­te­mu nie powin­na być tajem­ni­cą, cena jest jaw­na z urzę­du, pozo­sta­je więc (moja) nie­wie­dza na temat tech­no­lo­gii i metod jakie zasto­su­je dostaw­ca (to co pre­zen­tu­je na swo­jej stro­nie WWW rzad­ko kie­dy jest praw­dą w pro­jek­tach, z tego co obserwuję).

Tak więc sko­ro ofer­ty zawie­ra­ją taki roz­rzut cen, to moim zda­niem sys­tem” jest zły, zarów­no oce­ny ofert (cena jako 100%) jak i two­rze­nia OPZ, któ­re z regu­ły są listą poboż­nych” życzeń pra­cow­ni­ków zama­wia­ją­ce­go. Bez zna­cze­nia jest to, czy tę listę opra­co­wał sam zama­wia­ją­cy czy zatrud­nio­ny ana­li­tyk reali­zu­ją­cy sesje warsz­ta­to­we, burze mózgów czy ankie­ty. Analiza punk­tów funk­cyj­nych, jako kon­ty­nu­acja tak opra­co­wa­nej listy wyma­gań, tym bar­dziej nie wró­ży nic sen­sow­ne­go, bo jak wspo­mnia­łem nie­daw­no Analityk (tak wewnętrz­ny jak i zewnętrz­ny) to nie dyk­ta­fon.

Tak więc mamy kolej­ny przy­kład, że sys­tem prze­tar­gów nie dzia­ła” jak powi­nien, nicze­go nie gwa­ran­tu­je poza zawy­ża­niem cen (utrzy­ma­nie dużej kor­po­ra­cji i jej akcjo­na­riu­szy kosz­tu­je, a wiel­kość fir­my nie gwa­ran­tu­je nicze­go w kwe­stii jako­ści prac pro­gra­mi­stycz­nych co poka­zu­ją kolej­ne afe­ry i upa­dłe pro­jek­ty nie tyl­ko w naszym kra­ju np. ostat­nio Fiasko bry­tyj­skiej kom­pu­te­ry­za­cji i lek­cja dla Polski), obec­nie PZP słu­ży raczej eli­mi­no­wa­niu mniej­szych i nie raz znacz­nie lep­szych i tań­szych firm.

A naj­bar­dziej mnie zaska­ku­je to, że ASSECO zło­ży­ło ofer­tę o 25% droż­szą niż ich spół­ka zależ­na ZETO Łódź. Czyżby ase­ku­ra­cja by pie­nią­dze nie uciekły?.