Zdolności organizacji są ważnym elementem programowania aplikacji sterowania, jednak krytyczne dla jakości okazują się zdolności poszczególnych osób. Nie jest niezwykła dziesięciokrotna różnica w ilości błędów popełnianych na tysiąc linii kodu przez najlepszego i najgorszego programistę lub najlepszy i najgorszy zespół. W związku z tym, że o jakości procesu decyduje jego najsłabszy element, mniejsza liczba błędów programisty oznacza mniej poprawek i zmian oraz większą produktywność.
Instytut Inżynierii Oprogramowania (ang. Software Engineering Institute ? SEI) opracował model wydajności, który pomaga organizacjom w tworzeniu oprogramowania ?w terminie i budżecie?. Niestety nie zawiera on wiele wskazówek dla inżyniera automatyka lub zespołu programistycznego. Na szczęcie SEI stworzyła dwa dodatkowe procesy: PSP ? Personal Software Proces (personalny proces tworzenia oprogramowania) dla osób chcących usprawniać własne działania oraz TSP ? Team Software Process (zespołowy proces tworzenia oprogramowania), które pomagają poprawić jakość zespołów.
Twórcą PSP jest Watts Humphrey, laureat Narodowego Medalu Technologicznego za 2005 r. Większość inżynierów dąży do poprawienia jakości swojej pracy, a PSP pokazuje inżynierom oprogramowania, w jaki sposób realizować swoje zadania w profesjonalny sposób. PSP stwarza rygor dla: procesów programistycznych (poprzez: definiowanie sposobów pomiaru własnej wydajności), śledzenia zmian, analizy problemów, uczenia się na błędach i aktualizoaktualizowania osobistych procedur na bazie lekcji z popełnionych błędów.
Bardzo łatwo jest popaść w złe nawyki w programowaniu. Każdy popełnia jakieś błędy w procesie tworzenia, ale niewielu systematycznie na nich się uczy się i nie popełnia ich ponownie. Jednakże podstawą poprawy jakości jest uczenie się na błędach i usprawnianie procesów. Dla przykładu: w czasie testów oprogramowania danego urządzenia wciąż napotykamy ten sam błąd, taki jak: niezainicjowana zmienna, ponowne użycie szczebla w drabinie programu C, niekompletne zaprojektowanie funkcjonalności, źle wprowadzone nazwy zmiennych lub niezrozumienie algorytmu sterowania. PSP pokazuje, jak uczyćsię na takich błędach i modyfikować proces tworzenia tak, aby zredukować lub eliminować przyszłe błędy. Taka nauka może polegać na: testowaniu mniejszych elementów, zewnętrznych przeglądach lub wcześniejszym analizowaniu kodu. Ostatecznie jednak to sprawa programisty, w jaki sposób zmieni proces tworzenia oprogramowania, by wyeliminować źródła błędów lub znajdywać je wcześniej.
SEI dostarcza podręcznik samouczek PSP. Nie jest to złoty środek, droga samodoskonalenia jest długa i trudna, jednak warto nią podróżować. Usprawnienia nie przychodzą łatwo, zwłaszcza jeśli nie jest się twórcą oprogramowania zbyt długo. Samouczek działa najlepiej, jeśli pracuje się przy kilku dużych projektach. Wymagane jest również stałe pisanie dziennika pracy poprzez wszystkie fazy projektu: planowanie, projektowanie, kodowanie, kompilowanie, testowanie i utrzymane. Zapisy dziennika pozwalają na ustalenie: podstaw pomiaru jakości, estymacji wielkości, zasobów i harmonogramów oraz praktycznego zetknięcia się z defektami i zarządzaniem problemami. Nagrodą za tę ciężką pracę jest lepsza zdolność wywiązywania się z zobowiązań poprzez prawidłowe szacowanie i planowanie pracy. Inżynierowie, którzy uczą się metody PSP, potrafią zmniejszyć błędy szacowania pracochłonności z 350% (praca zajęła 3,5 razy dłużej, niż się spodziewano) do mniej niż 10%. Całkowita liczba błędów programistycznych na tysiąc linii kodu spadła o ponad 75%.
TSP to podobne narzędzia poprawy działania dla kierowników projektów, kierowników, którzy głównie są samodzielnymi programistami. Szczególny nacisk jest kładzionyna tworzenie harmonogramów i szacowanie pracochłonności. Kierownicy projektów programistycznych są postrzegani jako przewodnicy, motywujący zespół do utrzymania jakości i doskonałości pracy. TSP dostarcza kierownikom narzędzi, pozwalających: śledzić proces, zbierać informacje, analizować rezultaty i wprowadzać ulepszenia. PSP i TSP razem ? dają podstawę dla oprogramowania o wysokiej jakości.
Dodatkowe informacje dostępne są na: www.sei.cmu. edu/tsp. Dennis Brandl jest prezesem BR&L Consulting, firmy konsultingowej w Cary w USA.dbrandl@brlconsulting.comArtykuł pod redakcją Andrzeja Sobczaka
