Trudna prawda. Procesy rozwoju oprogramowania poza kontrolą

Warto mierzyć efektywność procesu produkcji oprogramowania, jednak przedtem należy upewnić się, że mierzymy właściwe parametry we właściwy sposób - to rekomendacja z badania przeprowadzonego przez Sofrecom i Procesowcy.pl.

Trudna prawda. Procesy rozwoju oprogramowania poza kontrolą
Trudna prawda. Procesy rozwoju oprogramowania poza kontrolą
Trudna prawda. Procesy rozwoju oprogramowania poza kontrolą

Rozwój oprogramowania w firmie obejmuje grupę procesów, które podlegają IT i CIO. Ich charakter nabiera cech procesów biznesowych, szczególnie w przypadku outsourcingu czy nadchodzącej rewolucji związanej z chmurą obliczeniową lub konsumeryzacją informatyki. To zawsze był obszar kluczowych kompetencji IT, którego jakość decydowała w zasadniczej mierze o znaczeniu i ocenie CIO i podległego mu obszaru w firmie przez resztę biznesu, wewnętrznych klientów.

W poprzednim numerze CIO Magazynu Dyrektorów IT zapowiadaliśmy raport podsumowujący badania dojrzałości procesów rozwoju oprogramowania w organizacjach w Polsce.

Zobacz również:

  • 9 cech wielkich liderów IT

Kompletny raport dostępny jest na stronach serwisu Procesowcy.pl oraz firmy sofrecom.pl. Jego tezy były dyskutowane w gronie dyrektorów IT podczas spotkania CIO Espresso, które odbyło się 28 września 2011 r. w Warszawie. W tym artykule przedstawiamy główne wnioski, które mogą stanowić podsumowanie przeprowadzonego badania.

Nieefektywnie planujemy czy nieskutecznie realizujemy?

Do podstawowych parametrów efektywności procesu produkcji oprogramowania należą: terminowość, poziom realizacji budżetu oraz jakość produktów na każdym etapie procesu, w tym produktu końcowego - oprogramowania, które zostaje dostarczone użytkownikowi.

Autorzy badania pytali organizacje o wartości parametrów osiągane w projektach z udziałem informatyki. Przy przyjętym progu akceptowalnego odchylenia do 10% aż 80% badanych organizacji przyznaje, że projekty przekraczają założenia budżetowe. Podobnie jest w przypadku dotrzymywania terminów: 79% projektów jest realizowanych dłużej, niż zakłada harmonogram. Nieco lepiej, choć nadal niezbyt imponująco, przedstawia się zagadnienie jakości produktów - 64% organizacji twierdzi, że w projektach realizowanych z udziałem IT nie są dotrzymywane założenia jakościowe. Co ciekawe, aż 10% organizacji zadeklarowało, że jakość w projektach w ogóle nie jest monitorowana.

Te wyniki potwierdzają potoczną opinię na temat terminowości, dotrzymywania założeń budżetowych i jakościowych w projektach realizowanych z udziałem IT. Jakie są przyczyny tak słabych wyników? Czy istnieje związek między brakiem efektywności a poziomem dojrzałości procesów rozwoju oprogramowania?

Jak planować?

Przyjrzyjmy się aspektom planowania w ramach procesów rozwoju oprogramowania. Aż 81% ankietowanych wskazało jako metodę określania pracochłonności i planowania projektów szacunki eksperckie (jest to subiektywna metoda oceny pracochłonności, bazująca wyłącznie na wiedzy i doświadczeniu prowadzących). Jak z tego wynika, najczęściej wykorzystywane jest najmniej ustrukturyzowane i sformalizowane podejście!

Ryzyko błędu ludzkiego jest największe, co również potwierdza przeprowadzone badanie: w grupie w taki sposób szacujących pracochłonność organizacji niedotrzymywanie terminów deklarowało aż 86% respondentów, a niedotrzymywanie budżetów - 87%.

Najlepsze wyniki uzyskano dla metody punktów funkcyjnych. Szacowanie tą metodą ma charakter obiektywny - złożoność oprogramowania wyrażona w liczbach pozwala na wyliczenie dni przypadających na pracownika, które są potrzebne do jego produkcji. Otrzymujemy w ten sposób wiarygodną podstawę do zaplanowania realnego harmonogramu i zaalokowania odpowiedniego budżetu. Spośród organizacji, które stosują metodę punktów frakcyjnych, co czwarta nie dotrzymuje harmonogramów, a co drugiej nie udaje się zakończyć prac w planowanym budżecie.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200