Oprócz XP i testów jednostkowych funkcjonuje także pojęcie "design by contract". Jest to technika pochodząca z języka Eiffel, w którym definiowane są "poprzedniki", czyli wymagania dla danego obiektu, "następniki" - opisujące to, czego należy oczekiwać po wykonaniu danej operacji, a także "niezmienniki" - elementy określające stan. W ten sposób definiowane są "zachowania" obiektów. Wbrew pozorom ten niby prosty mechanizm jest bardzo potężny - pozwala "z zewnątrz" kontrolować, czy dana klasa zachowuje się zgodnie z założeniami. Przypomina to trochę testy jednostkowe, jednak jest zupełnie odrębną techniką. Kontrowersyjnym pomysłem jest tzw. programowanie w parach - każdy programista tworzy kod, a inna osoba na bieżąco go sprawdza. Niestety, takie podejście jest trudne do osiągnięcia w realnych warunkach.

Innym filarem XP jest iteracja polegająca na częstym generowaniu kolejnych wersji. Stąd właśnie tak istotny jest udział klienta w projekcie, bo on decyduje o kolejnych wymaganiach stawianych przed programistami. W takich okolicznościach nieścisłości są łatwe do wychwycenia - klient nie tylko może (ze względu na wiedzę o biznesie), ale w praktyce musi sprawdzić, czy projekt idzie w dobrym kierunku, co w oczywisty sposób służy jakości. Z drugiej strony, proces budowy oprogramowania forsowany przez metodykę eXtreme Programming powoduje, że generalna jakość kodu źródłowego ciągle się obniża. Decydując się na XP, firma musi więc uwzględnić czas potrzebny na proces refaktoryzacji kodu, czyli jego porządkowania (refaktoring).

Refaktoryzacja dotyczy głównie języków obiektowych trzeciej generacji (C++, C#, Java itp.), ale jest możliwa w odniesieniu do każdego języka. Są narzędzia, które pozwalają wykonać taki proces w C czy nawet w Fortranie. Refaktoryzacja to nie są proste operacje "zamień i zastąp" w edytorze tekstowym. To może być np. "wyciągnij interfejs" albo "przesuń funkcję do klasy nadrzędnej". Jeżeli w wyniku refaktoryzacji zmieniają się jakieś literały w kodzie, to odpowiednie narzędzie zmodyfikuje kod we wszystkich odwołaniach do danego literału.

Na pytanie: Czy pisać zgodnie z Prince II, XP czy też inną metodologią, nie ma niestety jednoznacznej odpowiedzi. Wiele firm łączy pewne elementy różnych metodyk. Przykładowo, testy jednostkowe, które są najszerzej obecne w XP, mogą być stosowane w każdym projekcie - na pewno nie zaszkodzą. Warto tu też wspomnieć, że Microsoft opracował "Microsoft Solution Framework" - zestaw narzędziowy do prowadzenia projektu. Nie jest to metodologia w pełnym tego słowa znaczeniu, ale raczej olbrzymi zbiór porad i dobrych praktyk określający, w jaki sposób konstruować zespół, jakich ról członków zespołu nie można łączyć, jak zarządzać kolejnymi iteracjami itp. Rational opracował z kolei tzw. RUP (Rational Unified Process), w którym oprócz zasad modelowania jest wsparcie ze strony konkretnych narzędzi.

CMM, czyli kwestia pomiaru

Często firma zadaje sobie pytania: Czy dany sposób produkcji oprogramowania jest "dobry" czy też "zły" oraz: Co to znaczy "dobry" lub "zły"? Przynajmniej w pewnym stopniu dylematy tego rodzaju rozwiązuje opracowana przez Software Engineering Institute metodyka określająca dojrzałość procesu programowania - Capability Maturity Model (CMM).

CMM wyróżnia pięć poziomów dojrzałości. CMM1 to poziom "początkowy" charakteryzujący etap rozwoju firmy produkującej oprogramowanie. To sytuacja, w której projekt "jakoś" się udaje - nie ma formalnej definicji procesów tworzenia oprogramowania, szacowania kosztów ani nawet planowania. Zarząd czy kierownictwo wie tylko, że jakiś projekt jest prowadzony. Najbardziej charakterystyczne dla CMM1 jest to, że sukces projektu zależy od wysiłku superprogramisty (-ów), i tym samym nie jest powtarzalny. Jednym z problemów w większości projektów jest tzw. superprogramista. Taka osoba wie "wszystko" o danym projekcie i od niej w dużej mierze zależy powodzenie projektu. Równocześnie jednak taka osoba jest wąskim gardłem całego procesu, a dodatkowo zwiększa ryzyko niepowodzenia (choroba, odejście z pracy itp.).

Aby osiągnąć CMM2 (efekt powtarzalności), firma musi nauczyć się planowania i analizy kosztów. To z kolei nie jest możliwe, jeżeli nie będą śledzone wymagania danego projektu, w tym zasoby i inne elementy oczekiwane przez zlecającego. Równocześnie CMM2 zakłada, że firma kontroluje zmiany, opracowała miary jakości produktów i stara się tę jakość utrzymywać na wysokim poziomie. Jeżeli firma osiągnie CMM3 (tzw. poziom "zdefiniowany"), to zarówno procesy zarządzania projektem, jak i proces "wytwarzania" oprogramowania są ustandaryzowane i opisane. Założenie jest takie, że każda osoba staje się dobrze funkcjonującym "trybikiem" w sprawnie funkcjonującej "maszynie" do tworzenia oprogramowania. Dodatkowo zakłada się wykształcenie przez firmę dokładnie sprecyzowanej polityki jakości i mechanizmów informowania zarządu o postępach. Skracając opis CMM3, można powiedzieć, że jest to stan, w którym w firmie nie ma superprogramisty.

Poziom CMM4 (tzw. zarządzany) wiąże się z opracowaniem mechanizmów pomiarów wydajności procesów i jakości produktu. Firma, która go osiągnęła, opracowała i wdrożyła wskaźniki, które precyzyjnie określają, na ile procesy są "dobre". Jeżeli dodatkowo na podstawie tych wyników firma przeprowadza kontrolowane zmiany w procesach, by polepszyć wskaźniki, osiągnęła poziom CMM5, tzw. zoptymalizowany.

Większość firm dąży do poziomu CMM3 - na tym poziomie procesy są już na tyle dobrze zdefiniowane, że wiadomo jak "produkuje się" oprogramowanie. CMM 4 i 5 są szczególnie przydatne w "raportowaniu" i rozważaniach dotyczących analizy procesów. Niestety, na listach CMM nie ma polskich firm - poza jednym chlubnym wyjątkiem - Motorola Global Software Group (GSG) - Kraków Software Center, które ma 5., najwyższy stopień CMM, uzyskany w lutym 2002 r. Warto tu dodać, że część firm wdraża pewne elementy związane z procesami opisywanymi przez CMM (czy wymaganiami IOS), ale bez formalnej certyfikacji. CMM jest po prostu dobrym wyznacznikiem tego, w jaki sposób powinna działać firma produkująca oprogramowanie.

Nie wszystko pod kontrolą, czyli SOA

Z punktu widzenia modelowania i całego procesu tworzenia aplikacji koncepcja SOA pozornie niewiele zmienia. Tak naprawdę określa sposób łączenia różnych usług na dosyć wysokim poziomie abstrakcji, zaś same usługi są kodowane standardowo. Jednak w przypadku aplikacji, w której wykorzystujemy usługi zewnętrzne, trzeba się dobrze zastanowić, jaka będzie sumaryczna jakość całego rozwiązania. Z góry można założyć, że nie będzie ona wyższa, niż jakość "najgorszego" z jego elementów składowych. Nie można takich rozważań pominąć, tworząc proces biznesowy, w którym twórca dopuszcza tak naprawdę "obcy" kod stanowiący część jego rozwiązania. Kompleksowych metodyk w tym zakresie na razie brak.