Wydaje się, że kanał RSS ze strony http://dialogbulletin.eu/pl/blog/feed został uszkodzony w wyniku błędu "undefined entity%" w linii 72.

Ogłoszenie

Uwaga: Portal jest przygotowywany do generalnego remontu. W związku z tym nie da się obecnie zakładać nowych kont. Prosimy o cierpliwość.

Najlepsze praktyki przemysłowe w projektowaniu oprogramowania i w usługach IT

Przemysłowe podejścia i techniki organizacji pracy warto zastosować w IT.

Referat przygotowany na konferencję użytkowników Oracle.
Prezentacja z tego wykładu znajduje się w załączniku.

Łasiczka z damą, czyli inny punkt widzenia

Najlepsze praktyki przemysłowe
w projektowaniu oprogramowania i w usługach IT

Iwona D. Bartczak
Business Dialog

Andrzej Góralczyk
Dyrekcja.pl 

Abstrakt. W referacie przedstawiono propozycje zastosowania wybranych najlepszych praktyk przemysłowych do zapewnienia jakości i produktywności w procesach projektowania sotware'u i świadczenia usług IT w przedsiębiorstwach. Sektor IT dopracował się szeregu specyficznych dla siebie rozwiązań w obu omawianych dziedzinach. Mimo to jakość oprogramowania w wielu obszarach zastosowań nadal wzbudza poważne zastrzeżenia użytkowników, a efektywność pracy działów IT w przedsiębiorstwach nadal pozostaje problemem. Wnioski i postulaty podnoszone przez uczestników projektów realizowanych przez Business Dialog i portal Dyrekcja.pl wskazują, że świadomość tych faktów jest powszechna w wśród kadry kierowniczej IT i niekiedy towarzyszy jej poszukiwanie lepszych rozwiązań w obu dziedzinach. Rośnie zainteresowanie najlepszymi praktykami wypracowanymi w przemyśle przetwórczym. Pojawiają się wycinkowe rozwiązania przeniesione wprost z przemysłu, jak np. podział pracy i ról w zespołach programistów, statystyczne sterowanie procesami przez jakość, czy Robust Engineering. Propozycje przedstawione w referacie idą dalej – ujmują te doświadczenia w sposób systematyczny, w ramach filozofii KAIZEN oraz pokazują przykłady przystosowania przemysłowych podejść i technik do zapewnienia jakości w projektowaniu software'u i do organizacji pracy działów IT.

Wprowadzenie

W rozwoju informatyki jako dziedziny działalności gospodarczej coraz wyraźniej widoczne jest poszukiwanie rozwiązań wypracowanych w innych sektorach. Obserwujemy ów trend na co dzień w toku projektów realizowanych z udziałem szefów informatyki przez Business Dialog i portal Dyrekcja.pl. Wśród postulatów podnoszonych przez uczestników tych projektów najwyraźniejsze dotyczą metod zapewnienia jakości oprogramowania oraz przebudowy roli informatyki w przedsiębiorstwach. Być może ważnym źródłem omawianego trendu jest niezadowolenie z poziomu jakości i produktywności osiąganych dotychczas technikami opracowywanymi samodzielnie przez informatyków.

Podobne zjawisko można było obserwować w historii bardziej dojrzałych sektorów, więc można przypuszczać, że dalsza ewolucja sposobów działania informatyki będzie w znacznym stopniu powtórką historii rozwoju przemysłu przetwórczego, najbardziej zaawansowanego pod względem zarządzania i organizacji pracy. Przypuszczenie to stanowi przesłankę zarysowanej poniżej propozycji przeniesienia najlepszych praktyk zarządzania z tradycyjnych dziedzin przemysłu do informatyki.

Inżynieria wartości i punkt widzenia Użytkownika

W tradycyjnych sektorach gospodarki ogólne ramy dla inżynierii projektowania, produkcji i procesów eksploatacji tworzy Inżynieria Wartości, która rozmaitymi metodami i technikami bada i ustala wymagania Klienta i Użytkownika, a następnie przekształca je w produkt – wyrób bądź usługę. Niektóre praktyki w projektowaniu i w obsłudze produktów informatyki mieszczą się w ogólnych ramach Inżynierii Wartości. Można je więc traktować jako punkt wyjścia do systematycznej, krok po kroku implementacji najlepszych praktyk przemysłowych do IT. Poniżej przedstawiamy systematykę podejść i metod Inżynierii Wartości ujętą w taki sposób, aby łatwo było w niej umiejscowić wybrane typowe praktyki projektowania oprogramowania oraz utrzymania infrastruktury informatycznej.

Projektowanie zintegrowane – wyższy stopień rozwoju projektowania równoległego (Concurrent Engineering), w którym poszczególne etapy procesu projektowania nakładają się na siebie i są wykonywane równolegle. Projektowanie zintegrowane jest możliwe pod dwoma warunkami: standard podstawowy produktu musi być dobrze określony (wiadomo co jest rowerem, a co samochodem), a komunikacja z Użytkownikiem i w łonie zespołu tworzącego nowy produkt musi być intensywna, pozbawiona barier.

W informatyce znany jest problem nadmiernie wydłużonego cyklu projektowania wg tradycyjnej metodologii „wodospadu” (waterfall model). Elementy projektowania równoległego pojawiają się w większych projektach budowy software'u, w szczególności w strefie otwartych standardów oprogramowania. Jednakże typowe dla współczesnej inżynierii oprogramowania rozwiązanie problemu wodospadu, mianowicie programowanie iteracyjne (szczupłe i ekstremalne) nie jest rozwiązaniem optymalnym. Zrodziło się zapewne dlatego, że nie są spełnione dwa wspomniane warunki – nie wiadomo do końca, czym jest projektowany produkt, a zespół projektantów pracuje „pod kloszem”. Wykorzystanie najlepszych praktyk projektowania zintegrowanego wymaga rozwiązania tych dwóch problemów.

Analiza wartości – ma na celu określenie minimalnego zestawu wymagań, które powinien spełniać produkt oraz znalezienie optymalnej pod względem ekonomicznym wielkości zasobów niezbędnych dla spełnienia tych wymagań (materiału, pracy, czasu, technologii, wyposażenia itd.). W sektorze informatyki postępuje się odwrotnie, z wiadomymi skutkami. Ocenia się na przykład, że aplikacje dla biznesu średnio mają 40% nadmiaru funkcjonalności, nigdy nie wykorzystywanego przez Użytkownika i są nadmiernie złożone jak na jego wymagania. Rozmiary infrastruktury także są zbyt wielkie na każdym szczeblu, od pojedynczego stanowiska pracy po wielkie systemy, a przez to jest ona nadmiernie kosztowna w całym jej cyklu życia. Przed informatyką stoi wyzwanie – rewolucja mentalna umożliwiająca uznanie punktu widzenia Klienta i Użytkownika jako JEDYNEJ podstawy dla definicji produktu i jego jakości.

Ekonomika cyklu życia produktu – odgrywa zasadniczą rolę w organizacji procesów projektowania, eksploatacji i wymiany produktu. W typowych przypadkach ok. 70% kosztów cyklu życia wyrobów takich, jak maszyny i urządzenia określanych jest na etapie projektowania. Należy przypuszczać, że podobnie jest z oprogramowaniem dla biznesu. Wśród najlepszych praktyk projektowania zapewniających ekonomiczność cyklu życia jest zasada formułowania założeń „od tyłu”: najpierw założenia dotyczące sposobu zakończenia okresu eksploatacji, następnie kolejno założenia określające plany obsługi (utrzymania infrastruktury), założenia użytkowe, założenia dotyczące rozruchu (uruchomienia eksploatacji), założenia określające sposób produkcji wyrobu i wreszcie założenia dotyczące organizacji procesów przedprodukcyjnych (produkcja próbna, testowanie, wykonanie prototypów). W metodologii projektowania software'u istnieją zaczątki podobnego podejścia, np. tzw. projektowanie kierowane testowaniem. Wydaje się zatem, że pełne wprowadzenie omawianej zasady dałoby się wprowadzić bez większych trudności.

„Druga noga” ekonomiki cyklu życia to organizacja utrzymania infrastruktury. Trzeba powiedzieć, że najlepsze plany obsługi, takie jak utrzymanie prewencyjne (zapobiegawcze) oraz produktywne (nastawione na maksimum efektu ekonomicznego w cyklu życia) należą do rzadkości zarówno w odniesieniu do wyposażenia tradycyjnego, jak i informatycznego. Jednakże w obszarze tradycyjnym najlepsze praktyki są kompletnymi systemami utrzymania i kompletnymi metodologiami, gotowymi do wykorzystania. Wykorzystanie ich wymaga m. in. modyfikacji miernika, jakim jest poziom obsługi (service level) oraz podejść do organizacji pracy działów IT uwarunkowanych wymogiem maksymalizacji tego wskaźnika.

Sterowanie przez jakość – według najlepszych praktyk jakość jest określana WYŁĄCZNIE przez Klienta, ale klientem jest zarówno Użytkownik urządzenia w firmie, jak i właściciel biznesu. Użytkownik wymaga określonego minimalnego, ale niezbędnego zestawu funkcji i cech produktu, a właściciel wymaga określonej progowej ekonomiczności procesów, w których system służy jako narzędzie. W ten sposób zostają określone granice, w których muszą mieścić się parametry rezultatu procesu. U podstaw sterowania przez jakość leży zasada, że utrzymanie rezultatu procesu w określonych granicach dokonuje się poprzez doskonalenie procesu, a nie np. poprzez selekcję rezultatów dobrych i odrzucanie niedobrych. Z drugiej strony wiadomo, że najlepszą strategią sterowania procesem jest redukowanie jego wariancji. W tradycyjnym przemyśle istnieją metodologie sterowania przez jakość właściwie każdym procesem.

W odniesieniu do procesów projektowania najbardziej rozpowszechnione metodologie to projektowanie eksperymentalne i projektowanie solidne (Robust Engineering). Znane są próby zastosowania obu metodologii do projektowania software'u, lecz doświadczenia te są fragmentaryczne i nie zostały upowszechnione.

W odniesieniu do procesów eksploatacji i obsługi stosowanych jest kilka metodologii sterowania przez jakość, z których najbardziej znane to SPC czyli Statystyczne Sterowanie Procesami oraz Sześć Sigma. Elementy obu podejść sprawdzają się ze znakomitymi wynikami w projektowaniu wielkich systemów informatycznych i aplikacji krytycznych w sektorze kosmicznym i obronnym i warte są upowszechnienia.

Inżynieria procesów – w jej ramach dwie metodologie nadają się do implementacji w ulepszaniu procesów projektowania i eksploatacji wyrobów i usług informatycznych – te same, które najpowszechniej stosowane są w przemyśle przetwórczym. Praktyczna Inżynieria Przemysłowa to metodologia ulepszania dokonywanego na niskich szczeblach organizacyjnych, najczęściej na szczeblu zespołu. Natomiast BPI czyli Przeprojektowanie Procesów Biznesowych, które można nazwać „łagodnym reengineeringiem” organizowane jest zazwyczaj i zarządzane ze szczebla przedsiębiorstwa.

Elementy pierwszej ze wspomnianych metodologii zaczynają pojawiać się w dziedzinie projektowania software'u w postaci podziału pracy pomiędzy osoby pełniące różne role w tym procesie np. analityka/architekta biznesowego, architekta systemów i aplikacji, programistów i testerów. Najlepsze praktyki przemysłowe nasuwają przypuszczenie, że właściwym kierunkiem ewolucji tego podziału pracy będzie łączenie dwóch pierwszych ról, jednakże dopiero wtedy, gdy pojawią się specjaliści o wysokich kompetencjach zarówno w dziedzinie użytkowania, jak i projektowania architektury produktów informatycznych.

Z punktu widzenia inżynierii procesów dziedzina utrzymania infrastruktury IT w przedsiębiorstwach wydaje się najbardziej zaniedbana, mimo upowszechniania najlepszych praktyk w rodzaju ITIL. Wydaje się, że u źródła tej słabości leży niedostateczne jeszcze rozumienie tych procesów biznesowych z punktu widzenia Klienta oraz zignorowanie najlepszych praktyk przemysłowych na rzecz podejść i technik wywodzących się z samej IT.

Podsumowując ten punkt można stwierdzić, że w zarządzaniu informatyką nieobecne są do tej pory zagadnienia ciągłości i płynności procesów, dystrybucji pracy, zdolności procesów itd.

KAIZEN sposobem na uprzemysłowienie informatyki

KAIZEN jest ogólną metodologią przejścia danej dziedziny gospodarki z rzemieślniczego do przemysłowego stadium rozwoju. Wiadomo, że zmiana o tak szerokim i głębokim zasięgu nie może dokonać się z dnia na dzień, wymaga nie tylko czasu, ale także systematycznego podejścia. Wśród wielu sprawdzonych w praktyce zalet KAIZEN jest to, że początek tej przemiany dokonywany jest z zastosowaniem technik organizatorskich wywodzących się z rzemiosła, które stopniowo uzupełniane są technikami profesjonalnej inżynierii i organizacji pracy.

Cele dalekosiężne programu KAIZEN dla IT mogą i chyba powinny być te same, co w przemyśle przetwórczym – rozwój ludzi, osiągnięcie radykalnej poprawy jakości produktów informatycznych i kilkunastokrotny wzrost produktywności w sektorze.

-------- Prezentacja z tego wykładu (także w załączniku poniżej)

Patrz także KAIZEN dla IT.