Programowanie do granic możliwości

Mansour Raad miał duży problem. Jego start-up, DiscoverCast, opracowywał oprogramowanie do wykrywania kolizji dla branży lotniczej — błędy w kodzie mogą kosztować życie. Ale pieniądze wyschły po pierwszej rundzie finansowania, a zatrudnienie dodatkowych programistów do ukończenia wersji odpornej na błędy nie wchodziło w rachubę.

Tak więc Raad zapoczątkował stosunkowo nową dyscyplinę kodowania zwaną programowaniem ekstremalnym. Zamiast pracować samodzielnie nad poszczególnymi zadaniami, programiści łączyli się w pary, jeden pisał kod, podczas gdy drugi obserwował i krytykował, zapewniając zarówno krytyczne oko, jak i niezwykle ważną kopię zapasową. [Moja żona] urodziła dziecko, ale projekt musiał być kontynuowany, mówi Raad. Ponieważ pokazywałem to innym ludziom, ktoś mógł wejść w moje buty. Firma dotrzymała terminów bez wzrostu błędów dzięki komunikacji.

Większość programistów nie jest bardziej zadowolona z jakości oprogramowania niż ich klienci. Obecnie coraz więcej osób próbuje znaleźć sposoby na stworzenie solidnego oprogramowania na rynku, który oczekuje nowych produktów i ulepszeń i chce je szybko. Coraz częściej firmy programistyczne zwracają się w stronę strategii rozwojowych o nazwach takich jak zwinny rozwój i ekstremalne, naładowane adrenaliną hasła programistyczne, które dobrze pasują do wizerunku programistów jako twardych bohaterów ery informacji. W rzeczywistości trend, który ma długą historię, sygnalizuje odrzucenie programowania primadonny na rzecz pracy zespołowej i współpracy.

W branży oprogramowania błędny kod od dawna jest akceptowany jako fakt, aczkolwiek obciążający i kosztowny ( zobacz Dlaczego oprogramowanie jest takie złe , DZIECI lipiec/sierpień 2002 ). Problem polega na tym, że w oprogramowaniu ludzie zbytnio ufają własnej pomysłowości, mówi Michael Stiefel, konsultant, który szkoli klientów w zakresie metod niezawodności oprogramowania. Patrzyłem, jak ci wszyscy młodzi kolesie w wieku 20 lat popełniają te same błędy, które popełnialiśmy w latach 70. i 80., i zastanawiam się, dlaczego znowu musimy przez to wszystko przechodzić.

Aby zmniejszyć liczbę błędów, reformatorzy promują podejścia do inżynierii oprogramowania znane w branży jako zwinne tworzenie oprogramowania, które kładą nacisk na pracę zespołową, współpracę z użytkownikami końcowymi i elastyczne podejście do zmian. Aby zbudować oprogramowanie do unikania kolizji, firma Raad wykorzystała jeden rodzaj programowania zwinnego, zwany programowaniem ekstremalnym, który kładzie nacisk na ciągłe testowanie oraz współpracę.

Jeśli będziesz w stanie zastosować [środowisko współpracy] z pełną mocą, jakość produktów będzie lepsza, mówi Michele Marchesi, wiodący zwolennik programowania ekstremalnego i profesor inżynierii elektrycznej na Uniwersytecie w Cagliari we Włoszech.

Jednym z najpotężniejszych aspektów programowania zwinnego jest tak zwane programowanie równorzędne, w którym programiści współpracują ze sobą i na zmianę piszą kod i wyjaśniają innym jego logikę. Pary są tymczasowe, okresowo dzielą się i wymieniają, aby zachęcić do jeszcze większej interakcji. Nowe oczy badają każdy fragment kodu, tworząc proces ciągłego przeglądu.

Dwie osoby mogą odrzucać pomysły od siebie nawzajem, mówi Frank Arkell, główny inżynier oprogramowania w firmie General Dynamics Decision Systems, która stosuje techniki współpracy od dwóch dekad. Aby zachować świeżość zespołów, General Dynamics zmienia je dla każdego projektu.

Kolejna zaleta programowania równorzędnego? Presja rówieśnicza. Nikt nie chce być osobą, która zwalnia, więc oboje pracują ciężej, mówi Scott W. Ambler, prezes Ronin International oraz autor i mówca na temat zwinnego rozwoju.

Wystawiony na próbę

Podejścia oparte na współpracy zmieniają również sposób testowania oprogramowania. Tradycyjnie testowanie było procesem dwuetapowym. Po pierwsze, programiści piszą kod w oparciu o wymagania. Następnie oddzielna grupa testuje wynik. Ale kiedy oprogramowanie zawiera miliony linijek kodu, dwuetapowy proces jest analogiczny do projektowania samochodu na papierze, budowania go, a następnie sprawdzania, czy projekt zadziałał.

Takie podejście po prostu nie zadziałało w przypadku programistów, takich jak Nicholas Stamos, dyrektor techniczny Waltham, MA Phase Forward. Firma Phase Forward opracowuje oprogramowanie do prowadzenia farmaceutycznych badań klinicznych, a jej produkty muszą spełniać rygorystyczne wymagania amerykańskiej Agencji ds. Żywności i Leków.

Stamos twierdzi, że Phase Forward spełnia te wymagania, po części dzięki bliskiej i stałej współpracy między programistami firmy a personelem ds. zapewnienia jakości. Nie możesz rzucić tego przez pawęż i mieć nadzieję, mówi. Jakość należy budować od pierwszego dnia. Kiedy programiści kończą komponent, zespół ds. jakości sprawdza ich pracę. Następnie drużyny zamieniają się miejscami na kolejną rundę poprawek błędów. Wreszcie zintegrowana aplikacja jest testowana pod kątem problemów z interakcją między komponentami. Zamiast starego dwuetapowego podejścia testowanie staje się interaktywnym, ciągłym procesem.

Niektóre firmy próbują podobnie iteracyjnego podejścia nie tylko do testowania, ale przede wszystkim do projektowania kodu. Cognizant Technology Solutions, firma konsultingowa z siedzibą w Teaneck w stanie New Jersey, odkryła, że ​​istniejące metody rozpoczynania od formalnych specyfikacji, a następnie pisania kodu w celu ich zaspokojenia mogły działać 20 lub 30 lat temu. Ale w świecie, który działa w sieci i potrzebuje elastyczności, formalność może oznaczać sztywność.

Kiedy próbowaliśmy wykorzystać tradycyjne procesy dla tych nowszych typów projektów, albo klienci byli naprawdę sfrustrowani, ponieważ zmusiliśmy ich do zamrożenia procesu, albo zespoły projektowe po prostu nie podążały za tym procesem, mówi dyrektor generalny Cognizant, Kumar Mahadeva. Zamiast tego projekty wykorzystują serię prototypów, po których następuje cykl uprzemysłowienia, co pozwala firmie radzić sobie z nagłymi zmianami ze strony klientów w sposób, który ma mniejszy wpływ na niezawodność niż dostosowywanie programu po jego zakończeniu. Przyszli użytkownicy zapewniają stały strumień informacji zwrotnych, gdy aplikacja nabiera kształtów.

Ale ostateczne ograniczenia jakości oprogramowania mogą nie leżeć w umiejętnościach programistów lub sile procesu rozwoju. To jest zagadka, przed którą stoimy dzisiaj my i wielu producentów: jaki jest akceptowalny poziom jakości? mówi James Hymel, dyrektor ds. inżynierii oprogramowania w firmie Motorola. Jeśli masz konkurentów, którzy produkują słodkie, tanie, ale wadliwe [produkty], a klienci twierdzą, że jest to akceptowalne – to znaczy wydają na nich swoje pieniądze – zostaniesz zakwestionowany.

Dzięki metodom takim jak zwinny rozwój, partnerstwo w zakresie rozwoju i testowania oraz zaangażowanie użytkowników końcowych, twórcy oprogramowania podejmują kroki w celu ulepszenia swojego produktu. Ale ostatecznie największym ograniczeniem dla jakości mogą być ci sami ludzie, którzy żądają jej najgłośniej: konsumenci.

ukryć