O przetargach napisano tak wiele krytycznych tekstów, więc po co ten? Nie będę się tu pastwił nad nimi. Zastanawia mnie co innego, i tu mała krytyka…

W prasie pojawiły się doniesienia o rozstrzyganym przetargu ogłoszonym przez [[ARiMR]]:

Asseco Poland za swoje prace zaproponowało 40,65 mln zł, a Sygnity 43,98 mln zł. W przetargu startowały też: konsorcjum ze spółką zależną Asseco – ZETO Łódź (29,36 mln zł) i konsorcjum z Infovide-Matrix (31,75 mln zł). Wybrana poprzednio [[oferta konsorcjum IT Works i Almaviva]] opiewała na 9,92 mln zł. Przetarg realizowany był według procedury ograniczonej przyspieszonej. Kryterium oceny ofert w tym postępowaniu była cena. (Oferta Comarchu najkorzystniejsza w przetargu ARiMR. wnp.pl | Informatyka. Informatyka dla przemysłu.).

Co mnie zastanawia? Przede wszystkim to, że „profesjonalne” firmy z ogromnym (jak twierdzą na swoich stronach) doświadczeniem, prezentują oferty opracowane na bazie  tej samej dokumentacji (w końcu to przetarg), a rozrzut cen tych ofert jest czterokrotny!!!

Nie może to być (tak sądzę) kwestią zakresu projektu, bo ten jest opisany w SIWZ (Specyfikacja Istotnych Warunków Zamówienia, ta zawiera Opis Przedmiotu Zamówienia). Czy na pewno? Wstępnie wydaje mi się, że są dwie możliwe przyczyny takiego rozrzutu: słaby OPZ albo różnice w sposobie i metodach pracy oferentów, tu wyceny i metod wytwarzania. Popatrzmy na kryteria oceny (źr. str. WWW AMRiR):

kryteria udzielenia zamówienia: Cena rocznego utrzymania ? 55%. Cena 1 Punktu Funkcyjnego – 35%. Gwarancja ? 10% gwarancja na oprogramowanie, funkcjonujące w dniu zakończenia obowiązywania umowy, rozpoczynająca się od dnia zakończenia umowy. Każdy miesiąc trwania gwarancji + 2,5 pkt., maksymalnie 10 pkt.

Jednym ze składników ceny jest  tak zwany „punkt funkcyjny”. Cóż to jest? To jedna z popularniejszych metod wyceny. Jak to działa? WIKI:

Podstawowym założeniem metody punktów funkcyjnych jest podzielenie oprogramowania na pięć składowych.

1. Zewnętrzne typy wejścia to metody dokonywania zmian w wewnętrznych danych systemu.
2. Zewnętrzne typy wyjścia to metody reprezentacji danych przechowywanych przez system. Przykładem są wydruki komputerowe. Dane wyświetlane na ekranie nie należą do tej kategorii, są kwalifikowane jako opisane poniżej zewnętrzne typy zapytań.
3. Logiczne wewnętrzne typy plików to pliki używane wewnętrznie przez system. We współczesnej informatyce pojęcie pliku zmieniło swoje znaczenie. Składową tą możemy interpretować jako zbiór danych opisujących obiekty danego typu, na przykład tabelę w relacyjnej bazie danych.
4. Zewnętrzne typy interfejsów plików to metody wymiany danych między innymi systemami informatycznymi. Przykładem może być interfejs umożliwiający pobieranie danych z aplikacji internetowej w formacie JSON lub pliki współdzielone między różnymi aplikacjami.
5. Zewnętrzne typy zapytań to metody odczytu danych z systemu nie powodujące ich modyfikacji. Przykładem jest zapytanie SELECT z języka SQL.

Wady metody wskazane w jej opisie w WIKI:

• Mimo że metoda jest najbardziej dopracowaną i najpopularniejszą metodą szacowania wartości funkcji ocenianego programu, to nie pozostaje ona bez wad. Jedną z nich, wskazaną już przez Albrechta, jest subiektywność wartościowania złożoności typu jako niskiej, średniej lub dużej. Istotność tej wady obecnie jest niwelowana opracowaną przez IFPUG metodyką oceny złożoności (file type complexity).
• Kolejnym problemem jest czasochłonność (koszt) procesu wyliczania punktów funkcyjnych, gdyż z powodu nieznanej dokładności takich wyliczeń nie jest stosowana automatyzacja. tego procesu , ponieważ nieznana jest w takim przypadku – nie wiadomo czy jest duża czy mała.
• Innym mankamentem jest to, że wyniki metody w przypadku małych systemów mogą być mało dokładne.
• Metoda punktów funkcyjnych nie bierze również pod uwagę złożoności implementacji algorytmów działających wewnątrz systemu.

(Punkt funkcyjny ? Wikipedia, wolna encyklopedia.)

Po pierwsze metoda powstała ponad 30 lat temu, gdy standardową metodyką tworzenia oprogramowania były metody strukturalne (bazują na odseparowanej liście funkcji przetwarzających dane przechowywane w odrębnej bazie danych w modelu relacyjnym stad przykład z SELECT’em w języku SQL). Metoda, choć archaiczna, jest nadal rozwijana i dość powszechnie stosowana. Dlaczego? Moim zdaniem dlatego, że bazuje na tak zwanej „perspektywie użytkownika”: Granice [zakresu analizy] powinien określać użytkownik w oparciu o swój punkt widzenia i zapotrzebowanie. Ograniczenia technologiczne nie powinny być brane pod uwagę podczas określania granic między współpracującymi systemami. Należy kierować się przy tym ich funkcjonalnością. (WIKI). Jest to łatwa i prosta metoda, nie wymaga zbyt dużych kompetencji (a pamiętajmy, że duże firmy często cechuje dość duża rotacja pracowników co nie sprzyja  gromadzeniu kompetencji).

Powszechnie przyjętą praktyką jest wycena wykonania dedykowanego oprogramowania na bazie opisu wymagań najczęściej w postaci „wymagań funkcjonalnych i poza-funkcjonalnych”. Jednak tak opisane wymagania to jedynie opis tego jaki efekt chce osiągnąć zamawiający, nic nie mówią o  tym „jak” on zostanie osiągnięty. Metod i narzędzi wytwarzania oprogramowania jest wiele, kompetencje  wykonawców także bardzo różne. W efekcie, moim zdaniem, ocena ofert na bazie takich specyfikacji to loteria. (moim zdaniem metody wyceny oparte na przypadkach użycia i obiektowych wzorcach projektowych ich implementacji są znacznie bardziej wiarygodne, opis przy innej okazji).

Drugi element to ocena oferentów. Bardzo często zamawiający narzuca ogromne wymagania finansowe na dostawców: wysokie wadium, wysokie wymagania na obroty roczne itp. Do tego lata doświadczeń itp. Popatrzmy na profesjonalizm inżynierii i umiejętności o podobnym charakterze:  co świadczy o mechaniku samochodowym? To ile lat naprawia samochody czy to jakie i jakimi metodami? Czy to, że zespół programistów to ludzie od 15 lat piszący oprogramowanie w Pascalu, pozwala uznać ich za bardzo dobrych specjalistów? W czym?

Dzisiaj na rynku inżynierii oprogramowania królują metody i narzędzia obiektowe (co by to nie miało znaczyć) a nie strukturalne, uznane dawno za nieefektywne w tworzeniu oprogramowania o charakterze biznesowym (o innym się nie wypowiadam ;)). Metody obiektowe są efektywniejsze zarówno na etapie analizy i projektowania jak i na etapie implementacji, ale wymagają zupełnie nowej wiedzy w stosunku do metod strukturalnych (niestety nasze uczelnie uczą głównie metod strukturalnych).

Czy powyższy rozrzut cen to efekt różnic w technologii stosowanej przez oferentów czy ich kompetencji? Osobiście stawiam głownie na nieskuteczność metody punktów funkcyjnych i własnie słabe kompetencje.

Trudno o inne wnioski. Za mało danych zawierają informacje z rozstrzyganych przetargów, a niestety oferty nie są publikowane (nie rozumiem dlaczego i nie ja jeden….). Argument, że oferta „jest poufna” do mnie nie przemawia, bo Urzędy nie mają chronionego know-how a więc logika nowego systemu nie powinna być tajemnicą, cena jest jawna z urzędu, pozostaje więc (moja)  niewiedza na temat technologii i metod jakie zastosuje dostawca (to co prezentuje na swojej stronie WWW rzadko kiedy jest prawdą w projektach, z tego co obserwuję).

Tak więc skoro oferty zawierają taki rozrzut cen, to moim zdaniem „system” jest zły, zarówno oceny ofert (cena jako 100%) jak i tworzenia OPZ, które z reguły są listą „pobożnych” życzeń pracowników zamawiającego. Bez znaczenia jest to, czy tę listę opracował  sam zamawiający czy zatrudniony analityk realizujący sesje warsztatowe, burze mózgów czy ankiety. Analiza punktów funkcyjnych, jako kontynuacja tak opracowanej listy wymagań, tym bardziej nie wróży nic sensownego, bo jak wspomniałem niedawno Analityk (tak wewnętrzny jak i zewnętrzny) to nie dyktafon.

Tak więc mamy kolejny przykład, że „system przetargów nie działa” jak powinien, niczego nie gwarantuje poza zawyżaniem cen (utrzymanie dużej korporacji i jej akcjonariuszy kosztuje, a wielkość firmy nie gwarantuje niczego w kwestii jakości prac programistycznych co pokazują kolejne afery i upadłe projekty nie tylko w naszym kraju np. ostatnio Fiasko brytyjskiej komputeryzacji i lekcja dla Polski), obecnie PZP służy raczej eliminowaniu mniejszych i nie raz znacznie lepszych i tańszych firm.

A najbardziej mnie zaskakuje to, że ASSECO złożyło ofertę o 25% droższą niż ich spółka zależna ZETO Łódź. Czyżby asekuracja by pieniądze nie uciekły?.