Nowoczesna firma, chcąc sprostać wymaganiom współczesnego rynku oprogramowania systemów informatycznych, jest skazana na ciągłe doskonalenie procesów wytwarzania oprogramowania. Wymagania użytkowników, konkurencja na rynku, regulacje prawne (np. przepisy bezpieczeństwa), technologia, a także wewnętrzne potrzeby firmy skłaniają do przyjęcia polityki nieustannej oceny i poprawy tych działań firmy, które są niezbędne do jej powodzenia na rynku.

Eliksir młodości

Z punktu widzenia technologii wszystkie firmy mają dzisiaj praktycznie ten sam poziom wyposażenia sprzętowego, wydajność systemów projektowania oprogramowania jest porównywalna, a projektanci i programiści korzystają z tych samych narzędzi, dostarczanych przez kilkadziesiąt głównych firm. To, co może różnicować firmy, to czynnik ludzki, kultura organizacyjna, efektywny system procesów produkcyjnych oraz wdrożony i skuteczny proces ciągłego doskonalenia.

Na początku swojej działalności firma dysponuje zwykle znacznym potencjałem intelektualnym i finansowym, które są siłą napędową pierwszych projektów. Po pewnym czasie niektóre rozwiązania organizacyjno-produkcyjne stabilizują się i określają możliwy do osiągnięcia maksymalny poziom jakości produktów. Jego podniesienie wymaga zmiany nie ilościowej (nowych technik, narzędzi, zmian w systemie), a jakościowej (zmiany systemu). Bycie konkurencyjnym na rynku oznacza po prostu nieustanną pracę nad poprawą jakości.

Zmiany należy, oczywiście, rozpocząć od tych elementów systemu wytwórczego, które powodują najwięcej problemów. Okazuje się jednak, że ich zidentyfikowanie nie jest łatwe. Przyczyny problemów nigdy nie występują pojedynczo, skutek, jaki wywołują, może być przedłużony w czasie, ludzie nie chcą przyznać się do popełnianych błędów, nie ma sprzyjającej atmosfery do wyciągania na światło dzienne naszych "grzechów" itd. W jaki sposób zatem dokonać analizy i zidentyfikować obszary niezbędne do podnoszenia jakości? Trudno podać uniwersalną receptę. Należy pamiętać o kilku zasadach. Przede wszystkim analiza i ocena procesów zachodzących w firmie musi być systematyczna, powtarzalna i całościowa. Analiza taka może być ukierunkowana na wybrany obszar działalności firmy lub procesów albo dotyczyć wszelkich aspektów jej systemu produkcyjnego i kierowniczego, a także otoczenia i kontaktów z klientami i kontrahentami.

W tym zakresie może przyczynić się do poprawy obszarów działalności organizacji, takich jak:

- wykorzystanie zasobów (optymalizacja)

- organizacja procesów ukierunkowana na rzeczywiste potrzeby biznesowe

- powstanie mechanizmów podtrzymania korporacyjnej kultury ciągłego doskonalenia

- elastyczność i łatwość dostosowywania się do wymagań klienta i rynku

- minimalizacja kosztów cyklu produkcyjnego

- maksymalizacja zadowolenia klienta.

Osiągnięcie poprawy w tych obszarach oznacza zwykle:

- niższe koszty: projektowania, rozwoju i konserwacji, obsługi klienta, krótsze cykle produkcyjne

- wiarygodną estymację projektu i ocenę ryzyka

- zmniejszone ryzyko przekroczenia czasu i kosztu projektu dzięki bardziej przewidywalnym rezultatom pracy kooperantów

- zmniejszenie kosztów przez odrzucenie niewłaściwych kooperantów w początkowej fazie projektu.

W świetle powyższej wizji ocena procesów zachodzących w firmie jawi się nam jako pierwszy i podstawowy element procesu doskonalenia. Podstawowy to znaczy niezbędny do podjęcia w przyszłości właściwych działań naprawczych, korygujących czy doskonalących. Pełna realizacja tego celu wymaga:

- skali pomiarowej, za pomocą której będzie można ulokować firmę na określonym poziomie "jakości" (dojrzałości)

- kryteriów rozmieszczania (oceny) procesów firmy na skali

- zestawu uznanych standardów, norm i praktyk, stanowiących pewien - wzorcowy model odniesienia

- prostego i jasnego mechanizmu komunikowania wyników oceny.

Warto podkreślić, że samodoskonalenie nie jest jedynym celem. Zmiana w organizacji jest zawsze ukierunkowana na podniesienie jakości obserwowanej przez klientów. Organizacja zmienia się nie tylko po to, aby być najlepsza. Chce być najlepsza w trosce (walce) o klienta. Dlatego wyniki analizy procesów zachodzących w firmie mogą służyć zarówno doskonaleniu procesów firmy, jak i określeniu poziomu jej dojrzałości produkcyjnej. Pierwszy aspekt służy firmie, drugi jest ważny dla jej klientów i kooperantów, umożliwiając ocenę zdolności do podjęcia współpracy lub przyjęcia zamówienia na określonym poziomie wiarygodności i jakości.

Zdaniem użytkownika, ocena poziomu dojrzałości firmy pozwala na:

- zmniejszenie ryzyka związanego z wyborem dostawcy rozwiązań informatycznych

- dostępność mechanizmów stałej kontroli ryzyka przedsięwzięcia

- możliwość wiarygodnych oszacowań projektu i jego realizacji przez firmy o różnym poziomie rozwoju (dojrzałości)

- zmniejszone ryzyko przekroczenia czasu i kosztu projektu dzięki bardziej przewidywalnym rezultatom kooperantów

- zmniejszenie kosztów przez zrezygnowanie z niewłaściwych kooperantów w początkowej fazie projektu.

Jak się do tego zabrać?

Zarządzanie przedsięwzięciami produkcji oprogramowania jest dziedziną stosunkowo młodą. Nie dziwią więc próby adaptowania tradycyjnych metod (technik) inżynierskich do warunków powstawania oprogramowania. Najbardziej ogólne podejście do procesu oceny i doskonalenia dowolnych procesów produkcyjnych podał amerykański statystyk Walter Shewhart. Jego proces spopularyzowany przez Edwarda Deminga, znaczącą postać w dziedzinie zarządzania jakością, składa się z 4 etapów i nazywany jest cyklem PDCA (Plan/Do/Check/Act):

Planowanie (pomyśl)

identyfikacja problemów

określenie ich przyczyn i skutków

zaplanowanie działań doskonalących.

Realizacja (spróbuj)

realizacja projektu poprawy.

Weryfikacja (oceń)

zebranie wyników działań

ocena rezultatów

określenie rzeczywistej poprawy

wykazanie usunięcia zaplanowanych problemów.

Upowszechnienie (rób)

ustalenie procedur eliminujących wystąpienie problemu

zmiana procedur w celu wykluczenia ponownego problemu

szkolenie.

Elementy tego modelu znajdziemy we wszystkich racjonalnych modelach doskonalenia. Punktem wyjścia dla każdego z nich jest sesja oceny bieżących praktyk produkcji oprogramowania w danej firmie ze ścisłym odniesieniem do jej kontekstu biznesowego, tzn. audyt lub przegląd projektu (produktów).

Warto podkreślić, że istotą modelu Shewharta jest jego cykliczność, która w sposób naturalny przechodzi w ciągłość. Nie tyle liczą się poważne zmiany w standardach pracy czy procedurach, co ich systematyczność i nieustanność. Przeprowadzenie pierwszej oceny systemu produkcji oprogramowania, dające podstawę do planowania działań, jest początkiem nie kończącego się cyklu kolejnych usprawnień. Na początku oczywiście będą wybrane najważniejsze problemy, aby po ich usunięciu, poprawiać te mniejsze itd.

Życie i rzeczywistość rynkowa same się zatroszczą, aby proces ten nigdy się nie kończył.

Normalizacja w kształtowaniu jakości

Doskonalenie procesów wytwórczych jest nieustannym celem organizacji. Jest on osiągany przez równoległą z głównym nurtem działalności firmy realizację projektów poprawy ukierunkowanych na trwałe rozwiązywanie problemów, usuwanie niezgodności i wad.

Wiąże się to z opisywanym już przeze mnie dążeniem do uprawdopodobnienia ścieżki prowadzącej do sukcesu w wybranym obszarze. Wyprostowanie drogi prowadzącej do sukcesu jest kosztowne. Projekt poprawy, wysiłek ludzki, zmiana kultury firmy itd. - wszystko to jest kosztem zmian, które jednak opłacają się w perspektywie strategicznej i powinny wciąż procentować. Dlatego zmiany muszą być udokumentowane i rzeczywiście wdrożone w organizacji. Najprostszym sposobem osiągnięcia tego celu jest standaryzacja działań lub ich normalizacja.

Cele normalizacji lub standaryzacji można podsumować następująco:

- uproszczenie i ograniczenie różnorodności

- ograniczenie zmienności

- oszczędność

- bezpieczeństwo

- zaspokojenie potrzeb społecznych

- wsparcie interesów klienta.

Każda firma w pewnym zakresie musi wypracować swoje standardy pracy. Istnieją także gotowe normy, po które łatwo sięgnąć, aby nie wyważać otwartych drzwi. Ze względu na szczupłość miejsca nie mogę rozwinąć tego tematu (ciekawszych norm związanych z oprogramowaniem jest w ISO kilkanaście, a są także normy IEEE i inne), ale pragnę zaproponować przegląd 3 znaczących pozycji, "o których się mówi".

ISO 9000-3 - arkusz opisujący zalecenia, dotyczące stosowania norm ISO 9000 w produkcji oprogramowania

CMM - standard de facto odnoszący się do oceny i metodyki doskonalenia jakości i produktywności firm produkujących oprogramowanie

ISO 15504 - najnowszy standard oceny procesów produkcji oprogramowania.

Model ISO 9000-3

Model ISO 9000-3 jest rozszerzeniem norm serii ISO 9000 o projektowanie i produkcję oprogramowania systemów komputerowych. Ze względu na to, że jest to model ogólnie znany i napisano o nim prawie wszystko, ograniczę się do przypomnienia podstawowych działań wynikających z modelowego systemu jakości i ich odwzorowania na praktyki związane z produkcją oprogramowania.

Norma ISO 9000 była znaczącym etapem w kierunku poprawy jakości produktów. Ma jednak ograniczenia, a jej istota jest bardzo często wypaczana. Po pierwsze, ograniczenia. Norma definiuje modelowy system jakości, którego celem jest zapewnienie powtarzalności i jednorodności produktów. Jego zadaniem jest doprowadzenie do zgodności produktu ze specyfikacją, zaś sprawy jakości projektowej i jej zgodności z wymaganiami i oczekiwaniami użytkownika są potraktowane ogólnie. Zarzut ten często jest formułowany w następujący sposób: "Certyfikat ISO 9000 może bez problemu otrzymać producent kamizelek ratunkowych z betonu". Prace rozwojowe nad normą koncentrują się obecnie właśnie na tym aspekcie systemu jakości, tzn. jak wspomóc firmę w spełnieniu podstawowego kryterium, jakim jest satysfakcja klienta. Czy można jednak to znormalizować?

System jakości oparty jest na Księdze Jakości - dokumencie opisującym działania na różnych poziomach. Podstawą certyfikacji jest zdefiniowanie procedur i wykazanie, że są stosowane. Oczywiście bardzo upraszczam i niech wybaczą mi to wszyscy audytorzy ISO 9000, ale uzyskanie certyfikatu jest naprawdę łatwe. Szczególnie, że na rynku jest wiele metodyk pozwalających przygotować się do certyfikacji (np. TickIt dla oprogramowania), a także coraz więcej książek typu: ISO 9000 dla opornych, ISO 9000 w 9000 sekund itd. Przewodniki te informują jak łatwo, przyjemnie, bez wysiłku i skutecznie otrzymać certyfikat ISO, ale nie podają, jak podnieść jakość. Czy rzeczywiście chodzi o to, aby mieć kolejne logo na opakowaniu, które skłoni klienta do zakupu? Sądzę, że w dużej liczbie przypadków ten aspekt systemu jakości był głównym motorem zainteresowania normą.

Model CMM

Wobec rosnących problemów z jakością, terminowością i kosztami oprogramowania oraz wymagań ze strony użytkownika Departament Obrony USA podjął w 1982 r. próbę ich rozwiązania. Wynikiem tego programu były m.in. powołanie SEI (Software Engineering Institute) i stworzenie języka Ada. W roku 1987 powstał kwestionariusz, którym posługiwano się do oceny poddostawców i wykonawców projektów oprogramowania dla tego departamentu. Kwestionariusz był wykazem pytań, które w spójny i obiektywny sposób oceniały stan procesu produkcji oprogramowania w badanej firmie.

Pytania dotyczyły 3 obszarów:

zarządzania organizacją i zasobami - funkcje, odpowiedzialność, pracownicy, inne zasoby i wsparcie

inżynierii oprogramowania - zakres, głębokość i zupełność procesu inżynierii oprogramowania oraz sposoby jego pomiaru (mierzenia), zarządzania i doskonalenia

narzędzi i technologii - zakres i skuteczność ich stosowania.

W roku 1991 SEI opublikowało CMM 1.0, model dojrzałości (Capability Maturity Model), przedstawiający ustrukturalizowane i zainspirowane pracami Crosby'ego wnioski z kilku lat doświadczeń, związanych z badaniem potencjału produkcyjnego kooperantów Departamentu Obrony USA. Model określa kluczowe obszary charakterystyczne dla poszczególnych poziomów rozwoju firmy oraz formułuje zalecenia, co do sposobów ich osiągnięcia. Jest nieustannie weryfikowany przez CMM Advisory Board, w skład którego weszli przedstawiciele SEI, przemysłu amerykańskiego oraz rządu USA. CMM stał się nieformalnym standardem w USA i w przodujących krajach na świecie.

Model CMM (Tab. 2) opisuje 5 kroków-poziomów, które pokonuje każda firma, chcąca się doskonalić. Poziomy te odpowiadają stadiom rozwoju praktyk wytwórczych oprogramowania w typowych firmach (do dzisiaj model CMM został zweryfikowany w kilkuset firmach poddanych ocenie wg jego kryteriów). Na każdym poziomie firma dysponuje innym potencjałem wytwórczym. Dzięki przechodzeniu na wyższe poziomy możliwości realizacji projektów informatycznych poprawiają się one, a ryzyko niepowodzenia maleje.

Poziom 1: Początkowy

Procesy produkcyjne są chaotyczne, realizowane spontanicznie, sukces projektu zależy od indywidualnego wysiłku pracowników. Firma działa bez sformalizowanych procedur, oceny ryzyka i kosztu oraz planowania projektu. Nie ma mechanizmów kontrolujących procesy i ich realizację. Używane narzędzia nie są zintegrowane z procesem ani ze sobą. Wyższa kadra kierownicza nie ma możliwości zrozumienia ani właściwego ingerowania w procesy produkcji oprogramowania. Przedsięwzięcia mogą zawdzięczać sukces tylko "heroicznemu" wysiłkowi całego zespołu projektowego. Nie jest to zasługa organizacji firmy, ale jej ludzi. Okres taki charakteryzuje w pewnym stopniu każdą firmę na początku działalności. Jest to naturalny etap rozwoju, nabierania doświadczeń. Istotne jest jednak, aby firma rozwijała się w kierunku wyższych poziomów, by dojrzewała.

Poziom 2: Powtarzalny

Wdrożony jest podstawowy proces śledzenia kosztu, harmonogramu i funkcjonalności przedsięwzięć. Proces jest zdyscyplinowany i powtarzalny. Firma wyciąga wnioski z poprzednich projektów, uczy się na włas-nych błędach z etapu początkowego, nabiera doświadczeń. To, że przetrwała na rynku, daje jej możliwość krytycznego spojrzenia na dotychczasowe dokonania w kierunku racjonalizacji działań i procesów. Na tym etapie rozwoju łatwo jest podejmować projekty podobne do poprzednich. Sukces osiągany jest przez właściwe zarządzanie projektem. Podjęcie się nowych niesie ze sobą wciąż znaczne ryzyko niepowodzenia. Firma ma ciągłe problemy z jakością i brakiem w pełni wykształconych mechanizmów (nawyku) ciągłego doskonalenia działalności.

Poziom 3: Zdefiniowany

Procesy kierownicze i produkcyjne są zdefiniowane, standaryzowane i zinteg-rowane z działalnością organizacji. Projekty używają tego samego, udokumentowanego wzorca procesu produkcji. Pojawiające się problemy są identyfikowane i rozwiązywane. Zostaje powołany Zespół ds. Procesów Wytwórczych (SEPG - Software Engineering Process Group), odpowiedzialny za ocenę i doskonalenie procesów wytwarzania oprogramowania, wprowadzanie nowych narzędzi i technologii (metod) wspomagających te procesy oraz dostarczający informacji o ich stanie i zmianach dotyczących kierownictwa firmy.

Poziom 4: Kierowany

Wprowadzony jest skuteczny system zbierania danych o projekcie, jego jakości i innych charakterystykach. Miary służące do kierowania produkcją są powszechnie stosowane. Tworzona jest baza danych metryk - charakterystyka produktywności firmy - która dostarcza wszystkim szczeblom i funkcjom organizacji wiarygodnych danych do wypracowywania decyzji projektowych itp. Na tym poziomie organizacja posługuje się kołem Deminga w celu nieustannego doskonalenia procesów.

Poziom 5: Optymalizujący

Na podstawie miar ilościowych i zwrotnego sprzężenia z procesem produkcyjnym realizowany jest stały program usprawniania jakości i produktywności działań. Automatyzacja procesu gromadzenia danych i jego upowszechnienie pozwalają kierownictwu nie tylko wypracowywać decyzje oparte na faktach, lecz także zająć się analizą procesów i ich doskonaleniem ze specjalnym uwzględnieniem zapobiegania problemom.

Zalety tak sformułowanego modelu są oczywiste. CMM zaprojektowano w celu wskazania możliwych sposobów usprawnienia technologii produkcji oprogramowania przez zasugerowanie działań, które są charakterystyczne na danym poziomie rozwoju. Model jest ewolucyjny z założenia. Zakłada dorastanie organizacji do osiągnięcia pełnej kontroli nad procesami produkcyjnymi oraz wypracowania mechanizmów samokontroli i weryfikacji rezultatów, które warunkują sukces. Ponadto rozpoznanie przez organizację stanu (poziomu), na którym znajduje się w danej chwili, wyznacza kolejne działania doskonalące, które należy podjąć, aby przejść na kolejny, wyższy poziom.

Praktyka i życie zwykle bywają bardziej skomplikowane niż model. Firmy będą dążyć do przejścia od razu na poziom 5. Choć jest to teoretycznie możliwe, to jednak nie zalecane przez twórców modelu. Kolejne poziomy są podstawą, bazą dla następnych. Możliwe jest pominięcie niektórych aspektów lub wyprzedzenie bieżącego poziomu w pewnych obszarach, ale niesie to ze sobą ryzyko wprowadzenia dysharmonii w systemie wytwórczym firmy. Nie można przecież nauczyć się bycia dorosłym, trzeba do tego cierpliwie dojrzeć.

Model ISO 15504

Początek lat 90. był okresem rozwoju różnych metod doskonalenia procesów. Ważnym krokiem na tej drodze było powstanie modelu CMM. Po nim zaczęto tworzyć kolejne branżowe modele, takie jak Bootstrap, Trillium, SQPA, STD, SAM. Przyniosły one nowe spojrzenie na sprawy dotyczące poprawy procesów. Ogromna popularność norm ISO 9000 sprawiła, że już nie tylko producenci, lecz także odbiorcy i użytkownicy oprogramowania włączyli się aktywnie w proces doskonalenia jakości oprogramowania, głównie przez zaostrzenie kryteriów odbioru produktów. Producenci, walcząc o klienta, muszą nie tylko dostarczyć gotowy produkt o zamówionej jakości, lecz także udowodnić (często jeszcze na poziomie negocjacji kontraktowych), że będą w stanie zamawiany produkt wykonać.

W rezultacie rosnącego zainteresowania tą dziedziną, w roku 1991, Ministerstwo Obrony Wlk. Brytanii przeprowadziło badania 25 przemysłowych standardów oceny i doskonalenia procesów. W wyniku tych badań stwierdzono pilną potrzebę stworzenia jednego, światowego standardu mogącego służyć jako przewodnik i metoda oceny procesów wytwarzania oprogramowania. W roku 1993 formalnie ukonstytuowano w ISO grupę roboczą projektu SPICE (Software Process Improvement and Capability dEtermination), która jest odpowiedzialna za przeprowadzenie nowego standardu przez ścieżkę legislacyjną. Nowy standard opublikowano jako ISO/IEC 15504 TR.

Standard SPICE jest odpowiedzią na potrzeby użytkowników i wytwórców oprogramowania. Dostarcza systematycznej i strukturalnej metody badania procesów produkcyjnych oraz kryteriów ich oceny, pozwalających na zebranie danych, które są:

obiektywne

powtarzalne

porównywalne

niezbędne do doskonalenia procesu

użyteczne do oceny zdatności procesu.

Właściwa ocena rzeczywistego stanu procesów wytwórczych jest pierwszym krokiem, od którego można zacząć:

definicję procesów produkcyjnych

przygotowanie skutecznego planu poprawy (zmian)

optymalizację wykorzystania zasobów

wybór najlepszego kooperanta na podstawie oceny stopnia zdatności jego procesów do danego zastosowania.

Ocena procesów produkcyjnych ma dwa główne konteksty użycia: doskonalenie procesu produkcyjnego i ocena zdatności procesów dostawcy dla potrzeb klienta. W obu przypadkach ocena przebiega w jednakowy sposób, lecz różna jest interpretacja wyników. W wypadku doskonalenia procesów wyniki wskazują bezpośrednio te obszary, w których procesy firmy są mniej dojrzałe. W przypadku oceny zdatności procesów dla potrzeb klienta wyniki są porównywane z wcześniej ustalonymi wymaganiami. Klient ma możliwość wyboru tej firmy, której profil procesów jak najmniej odbiega od "ideału", określonego przez wymagania.

Ocena procesów prowadząca do stworzenia profilu zdatności (potencjału produkcyjnego) firmy polega na porównaniu z modelem referencyjnym standardu SPICE. Model ten ma dwa wymiary: procesu i zdatności. W wymiarze procesu model dostarcza zestaw podstawowych (wzorcowych) procesów produkcyjnych, które muszą wystąpić w każdej organizacji produkującej oprogramowanie. Wszystkie procesy są zgrupowane w 5 głównych kategorii związanych z organizacją, zarządzaniem, kontaktami z klientem, inżynierią oprogramowania i wsparciem. Każdy zawiera wiele praktyk, które są wymagane do jego pełnej realizacji. Praktyki te są zdefiniowane w standardzie ISO 12207, do którego model SPICE się odwołuje. Ocena, w jakim stopniu dany proces jest realizowany w danej firmie, jest dokonywana w wymiarze zdatności procesu. W tym wymiarze mamy do czynienia z zestawem 9 atrybutów zarządzania procesem, zgrupowanych w 5 poziomów dojrzałości (podobnych do CMM). Te same atrybuty mają zastosowanie do każdego procesu.

Powiększ

Standard SPICE nie jest standardem doskonalenia w takim sensie, jak CMM, który - lokując pewne procesy na poziomach dojrzałości - sugeruje kolejność i priorytety ich poprawy. SPICE jest bardziej elastyczny. Pozwala szczegółowo przedstawić, co jest źle, ale sposób wprowadzenia zmian, ich zakres itd. pozostawia firmie. Ma to dobre i złe strony.

Podsumowanie

Doskonalenie jakości jest naturalnym wymaganiem dla firmy funkcjonującej na rynku. Konkurencyjność jest związana z ciągłą poprawą jakości produktów. W tym celu równolegle z działalnością produkcyjną firma musi prowadzić wewnętrzne projekty ukierunkowane na stabilizację najlepszych praktyk. Standard i procedura postępowania są dla firmy wynikiem udokumentowania jednej, prostej ścieżki prowadzącej do sukcesu. Proces ten nie jest łatwy, a jego "odkrywanie" przez każdą firmę jest kosztowne. Normy i standardy międzynarodowe lub lokalne są gotowym produktem, którego zakup i wdrożenie może gwarantować szybki sukces.

Napisałem "może", bo jeśli rzeczywistość i praktyka nie zgadzają się z normą, oznacza to z dużym prawdopodobieństwem, że trzeba poprawić nie proces, lecz normę. Jak w życiu...

Tomasz Byzia jest konsultantem w InfoViDE.