Wdrażanie technologii CASE (Cz. 3)

W poprzednich odcinkach przedstawiliśmy kilka praktycznych porad, które nasunęły się nam w związku z tymi próbami zastosowania technologii CASE, które mieliśmy okazję obserwować lub prowadzić. Uwagi te miały, z definicji, nieco nieuporządkowany charakter. W dzisiejszym odcinku chcielibyśmy podejść do zagadnienia w sposób bardziej systematyczny i napisać szerzej o zagadnieniach związanych z systemami CASE i metodykami strukturalnymi, ukazując je na tle bardziej ogólnym - na tle zarządzania procesem produkcji oprogramowania. Związek z metodykami strukturalnymi i narzędziami CASE traktujemy tutaj dosyć luźno, jako że tzw. process management dotyczy nie tylko metodyk strukturalnych. Chcielibyśmy zatem napisać nie tylko o metodykach strukturalnych, ale także o tym, jak poprawić proces produkcji oprogramowania, przechodząc od chaosu do wyższych poziomów rozwoju i co to właściwie znaczy.

W poprzednich odcinkach przedstawiliśmy kilka praktycznych porad, które nasunęły się nam w związku z tymi próbami zastosowania technologii CASE, które mieliśmy okazję obserwować lub prowadzić. Uwagi te miały, z definicji, nieco nieuporządkowany charakter. W dzisiejszym odcinku chcielibyśmy podejść do zagadnienia w sposób bardziej systematyczny i napisać szerzej o zagadnieniach związanych z systemami CASE i metodykami strukturalnymi, ukazując je na tle bardziej ogólnym - na tle zarządzania procesem produkcji oprogramowania. Związek z metodykami strukturalnymi i narzędziami CASE traktujemy tutaj dosyć luźno, jako że tzw. process management dotyczy nie tylko metodyk strukturalnych. Chcielibyśmy zatem napisać nie tylko o metodykach strukturalnych, ale także o tym, jak poprawić proces produkcji oprogramowania, przechodząc od chaosu do wyższych poziomów rozwoju i co to właściwie znaczy.

Zacznijmy zatem od przypomnienia podstaw naszego rozumowania. Otóż powszechnie znanym faktem jest to, że motorem napędzającym rozwój informatyki jest szeroko rozumiany biznes (różne instytucje rządowe). Informatyka nie napędza się sama i firmy software'owe zazwyczaj nie zamawiają u siebie oprogramowania nawzajem. Zawsze, gdzieś "na końcu" łańcuszka zainteresowanych badaniami i rozwojem informatyki jest ktoś, kto za to wszystko płaci i na ogół jest to prywatny przedsiębiorca lub podatnik reprezentowany przez agendę rządową.

Skoro zatem informatyka ma być dyscypliną inżynierską, istniejącą w celu zaspokajania potrzeb praktycznych, to mamy prawo domagać się wykształcenia takich metod pracy zespołów informatycznych, aby były one zdolne wytwarzać oprogramowanie metodami przemysłowymi. "Przemysłowość" wytwarzania kojarzy się nam z takimi pozytywnymi cechami procesu produkcji, które dały się już osiągnąć np. w produkcji samochodów, a niezbyt łatwo dają się osiągnąć w produkcji oprogramowania:

  • Przewidywalność i powtarzalność procesu produkcyjnego, możliwość dokładnego planowania produkcji, sporządzania harmonogramów prac, ich kontroli etc.

  • Jasne, precyzyjne i udokumentowane kryteria i procedury oceny jakości powstających produktów.

  • Sprawna, przejrzysta i udokumentowana organizacja produkcji.

  • Niezależność procesu produkcyjnego od realizujących go ludzi (choroba lub zwolnienie jednego lub kilku pracowników nie mają żadnego wpływu na produkcję samochodów).

  • Niezależność procesu produkcyjnego od konkretnego produktu (emitowano kiedyś w telewizji film, pokazujący taśmę montażową japońskiej fabryki samochodów, po której przesuwały się montowane samochody osobowe, a co jakiś czas... półciężarówka).

  • Istnienie dokumentacji produktu i wszystkich aspektów procesu produkcyjnego.

  • Ciągła poprawa procesu produkcyjnego wymuszana naporem konkurencji, rosnącymi wymaganiami klientów, wynikami badań, koniecznością obniżenia kosztów, poprawy jakości etc.
Czy zastanawialiście się Państwo kiedyś, co by było, gdyby samochody były produkowane tymi samymi metodami, co oprogramowanie? Strach pomyśleć! Byłoby wtedy tak, jak w opowieści pracownika pewnej fabryki "rowerów" w Polsce -"co zacznę składać rower, to wychodzi mi karabin".