Prof. David L. Parnas jest uznawany za twórcę modułowej struktury oprogramowania. Wiele lat pracował jako konsultant Departamentu Obrony USA, gdzie określił procedury tworzenia programów o krytycznym znaczeniu dla bezpieczeństwa działania systemów. Współpracował również z wieloma firmami, m.in. Bell Labs, Lucent i IBM. W ostatnich latach pracował nad koncepcją nowego systemu edukacji informatyków. W kwietniu br. nakładem wydawnictwa Addison-Wesley ukazała się książka Software Fundamentals: Collected Papers by David L. Parnas, w której zgromadzono 33 najważniejsze jego prace, poświęcone inżynierii oprogramowania i teoretycznym podstawom tej dziedziny. Z profesorem Davidem L. Parnasem, o tworzeniu bezpiecznego oprogramowania, rozmawia Przemysław Gamdzyk.

W Polsce niedawno złożył wizytę Jim Highsmith...Jim Highsmith?

Guru od adaptacyjnego programowania. W ubiegłym roku jego książkę na ten temat opublikowało wydawnictwo Addison-Wesley.

Naprawdę nie znam. Znam natomiast taki dowcip: "W hotelu rozmawiają dwie sprzątaczki: ta informatyka to chyba jakaś ogromna i ważna dziedzina, bo co tydzień ma u nas wykład światowej sławy informatyk. Co ciekawe, każdy następny nie słyszał nigdy o którymkolwiek z poprzednich".

Chciałem zapytać o Pana opinię na temat nowych metod tworzenia oprogramowania, np. programowania ekstremalnego.

Jestem bardzo sceptyczny. To wszystko tylko z pozoru wygląda rewelacyjnie. Owszem, łatwo o rezultaty. Szybkie rezultaty. Ale szybkość nie zawsze znaczy jakość. Praca posuwa się, nie trzeba sobie zaprzątać głowy różnymi zadaniami, pomija się dokumentację, metodyczne testowanie - liczy się bowiem programowanie.

Łatwo o sukces, o przygotowanie czegoś, co ucieszy klienta. Kłopoty zaczynają się później. Wtedy gdy projekt jest już skończony, a ludzie z zespołu, którzy się nim zajmowali, przeszli do innych zadań albo odeszli z firmy. Kiedy okazuje się, że trzeba zintegrować kilka systemów. Albo kiedy powinno się zmodyfikować oprogramowanie. Tak już jest, że każdy fragment oprogramowania, którego się używa, prędzej czy później musi zostać zmodyfikowany. Wówczas okazuje się, że pewna nonszalancja w dokumentowaniu prac sprawia, że sytuacja staje się naprawdę trudna. A właśnie w tym celu powinno się starannie i dokładnie dokumentować proces powstawania systemu. Informatyka będzie dojrzałą dziedziną inżynierską tylko wtedy, gdy od początku będzie się dbać o jakość tworzonego oprogramowania. Przestańmy się skupiać wyłącznie na wersji 1.0, zacznijmy myśleć o oprogramowaniu w perspektywie wielu lat jego używania.

Apologeci programowania adaptacyjnego twierdzą, że trzeba budować po kawałku, nie zaś według gotowej specyfikacji.

To nic nowego. Techniki przyrostowe powstały przed 25 laty. Zapewne tak duży opór wobec metod formalnych bierze się z tego, że wiele z nich to bardzo, ale to bardzo złe metody. Weźmy dla przykładu rzecz fundamentalną, jaką jest specyfikacja wymagań. Na ogół traci się z oczu cel, dla którego ona w ogóle powstaje.

Co komu po specyfikacji wymagań, jeśli nie jest ona używana? Ile razy miałem do czynienia z projektami, w których opasłe tomy dokumentacji wymagań były pokryte grubą warstwą kurzu. Bardzo dobrze, jeśli takie dokumenty mają postrzępione brzegi kartek, ślady używania. Ideał to sytuacja, w której na stronach widać odciski od filiżanek z kawą. To najlepszy znak, że dokumentacja rzeczywiście się przydała.

Żeby dokumentacja była przydatna, to musi być czytana. Oczywiście, powinni do niej powracać ci, którzy tworzą aplikację. Specyfikacja wyznacza przecież dalszą drogę postępowania. Ale co z przyszłym użytkownikiem? Przecież na ogół nie ma on kwalifikacji informatycznych.

Specyfikacja wymagań powinna być tak napisana, żeby bez problemu zrozumiał ją użytkownik. W przeciwnym razie, nie będzie mógł on zweryfikować jej poprawności. Wtedy taka dokumentacja jest warta tyle, co sterta makulatury. Posługiwanie się skomplikowanymi formułami sprawia, że czyta się je znacznie trudniej niż kod! To absurd. Wtedy oczywiście nikt takiej specyfikacji nie przeczyta, zostanie ona tylko raz przez kogoś napisana i odłożona na półkę.