Co powinniśmy zapamiętać

Kodowanie na podstawie projektu

Podstawowym zadaniem programisty jest napisanie kodu, który będzie zgodny z projektem stworzonym przez architekta i projektanta kodowanych komponentów. Przeniesienie projektu systemu opisanego modelami projektowymi do kodu nazywane jest inżynierią w przód. Część kodu może być oparta bezpośrednio np. na modelach klas oraz sekwencji. Dobrą praktyką implementacji jest utrzymywanie jej zgodności z modelami projektowymi. W ten sposób, programiści mają stale aktualną „mapę kodu”. Aby zachować zgodność aktualizowanego kodu z projektem, można zastosować inżynierię odwrotną.

Dobre praktyki kodowania

Dobrej jakości kod tworzony jest na podstawie dobrej jakości projektu. Oznacza to, że dobre praktyki kodowania często pokrywają się z dobrymi praktykami projektowania.  Dobre praktyki kodowania są niezależnie od języka programowania, rozwiązań technicznych, charakteru organizacji informatycznej czy dziedziny projektu, w obrębie którego kod powstawał. Można je podzielić na praktyki redaktorskie, merytoryczne oraz związane z nawykami codziennej pracy. Praktyki redaktorskie dotyczą formatowania tekstu, komentowania kodu oraz konwencji nazewniczych. Praktyki merytoryczne dotyczą m.in. zasad projektowania podczas kodowania, zapewnienia parametryzowalności kodu, posługiwania się wzorcami projektowymi, przestrzegania walidacji parametrów wejściowych, dbałości o dane i zasoby maszyny, brania pod uwagę przenośności i skalowalności. Praktyki związane z nawykami dotyczą m.in. zapewnienia „czystości” własnego kodu, pracy na aktualnym kodzie, umiejętnego korzystania ze środowiska programistycznego.

Zarządzanie wersjami, konfiguracją i zmianami

Zarządzanie wersjami oznacza zapisywanie kolejnych zmian w pliku lub zestawie plików, czyli tworzenie kolejnych wersji. Zarządzanie zmianami w projektach konstrukcji oprogramowania najczęściej dotyczy plików z kodem źródłowym, lecz może ono być stosowane do dowolnego rodzaju plików. Do zarządzania wersjami stosujemy specjalne narzędzia, które nazywamy systemami zarządzania wersjami. Istnieją dwa główne modele zarządzania wersjami: scentralizowane (klient-serwer) oraz rozproszone. Zarządzanie zmianami polega na stosowaniu odpowiedniego procesu obsługi zmian, które pojawiają się w różnych fazach projektu. Zmiany mogą być wynikiem okoliczności związanych ze sposobem rozwoju oprogramowania, a także czynników zewnętrznych: zmian prawnych, organizacyjnych, cyklu koniunkturalnego, potrzeb użytkowników, rozwoju infrastruktury, wyników analizy działania systemu w obrębie wspieranego biznesu itd. Zarządzanie konfiguracją polega na tworzeniu kolejnych wydań systemu składających się z szeregu produktów procesu wytwórczego, takich jak kod źródłowy, kod wykonywalny, modele projektowe, dokumentacja techniczna, itd.

Rola testowania

Testowanie oprogramowania jest dyscypliną inżynierii oprogramowania zajmującą się określaniem metod oraz przeprowadzaniem badania poprawności działania oprogramowania. Odstępstwa od ustalonych wymagań odnośnie systemu nazywamy błędami oprogramowania. Obejmują one sytuacje, kiedy oprogramowanie nie wykonuje czegoś, co powinno wykonywać, oprogramowanie robi coś, czego nie powinno robić, oprogramowanie nie wypełnia warunków dotyczących cech pozafunkcjonalnych, lub zachowuje się w sposób nie przewidziany specyfikacją. Istotną część błędów stanowią pluskwy – usterki umiejscowione w kodzie programu i wynikające ze zmęczenia, przeoczeń bądź nieuwagi programistów. Nie jesteśmy w stanie udowodnić prawidłowości działania systemu poprzez sprawdzenie wszystkich możliwych scenariuszy dla wszystkich możliwych danych. Potrzebne jest uzyskanie odpowiedniej równowagi między środkami poświęconymi na testowanie, a uzyskanym efektem (jakością oprogramowania).

Podstawowe metody testowania

Najczęściej używanymi metodami testowania są metody kierujące się zasadą testów czarnej skrzynki.  By przeprowadzić udany test metodą czarnej skrzynki należy wykorzystać techniki weryfikacji oprogramowania bazujące na zasadach nieingerencji i nieznajomości kod programu. Należą do nich metody tworzenia klas równoważności, warunków granicznych, zmian stanów oraz niedoświadczonego użytkownika. Przeciwwagą dla metod czarnej skrzynki są metody szklanej (białej) skrzynki. Wykorzystują one wiedzę o kodzie programu w celu podniesienia skuteczności testów. Testy bazujące na wglądzie w strukturę programu polegają przede wszystkim na badaniu kodu przy pomocy różnych technik, badających m.in. pokrycie instrukcji, gałęzi, warunków, działanie pętli oraz ścieżek bazowych.

Poziomy testowania

Testy możemy skategoryzować w zależności od ich rodzaju oraz etapu procesu wytwarzania oprogramowania, na którym należy zacząć je stosować. Różne rodzaje testów mogą być i typowo są wykonywane przez osoby pełniące różne role w projekcie. Na przykład, testy jednostkowe wykonywane są przez programistów, a testy akceptacyjne – przez dedykowanych testerów we współpracy z użytkownikami. Najbardziej szczegółowym rodzajem testów są testy jednostkowe. Dotyczą one kodu systemu i są tworzone bezpośrednio przez programistów go piszących. Rolą testów jednostkowych jest sprawdzenie działania elementarnych składników kodu, np. klas oraz ich metod. Testy regresyjne są to testy powtarzane w identyczny sposób w kolejnych iteracjach projektu, mające na celu sprawdzenie, czy wprowadzone w kodzie zmiany nie spowodowały powstania nowych błędów. Testy kodu, w których testujemy większą liczbę współpracujących ze sobą elementów naraz (np. cały komponent) nazywamy testami modułowymi. Rolą testami integracyjnych jest sprawdzanie poprawnej współpracy wielu różnych elementów. W skład tej kategorii wchodzą również testy współdziałania i testy systemowe. Najwyższym poziomem testów są testy akceptacyjne, które mają dowieść zgodności systemu z wymaganiami, co pozwoli na jego ostateczny odbiór przez klienta.

Testowanie przypadków użycia

Testowanie akceptacyjne najczęściej polega na testowania działania przypadków użycia i jest wykonywane na poziomie testów systemowych i testów akceptacyjnych. Testy polegają na projektowaniu, a następnie wykonywaniu scenariuszy testowych. Scenariusz testowy opisuje kolejne kroki interakcji użytkownika z systemem, prowadzące do uzyskania określonego efektu. Scenariusz pozytywny ma na celu zbadanie zachowania systemu, które jest pożądane z puntu widzenia wymagań użytkowników. Scenariusz negatywny ma na celu upewnienie się, że system nie wykazuje zachowań niezgodnych z wymaganiami.

Stosowanie narzędzi

Aby praca  informatyków była nie tylko wydajna i zakończona sukcesem, ale w ogóle możliwa, niezbędne jest powstanie odpowiedniego środowiska, w którym te tworzone artefakty są właściwie uporządkowane. Takie środowisko pracy powinno pozwalać nie tylko na łatwą wymianę informacji między uczestnikami projektu, ale również na automatyzację możliwie wielu czynności na wszystkich etapach procesu wytwórczego. W celu usprawnienia pracy zespołów konstruujących systemy oprogramowania, powstały różnego rodzaju narzędzia, które nazywamy narzędziami komputerowego wsparcia inżynierii oprogramowania.

Narzędzia analizy i projektowania

Bardzo istotną rolę w warsztacie twórców oprogramowania spełniają narzędzia modelowania obiektowego. Pozwalają one m.in. na kontrolę poprawności notacji modeli, generowanie szkieletowego kodu na podstawie modeli czy też generowanie dokumentacji modeli. Projektowanie baz danych ułatwiają narzędzia do zarządzania bazami danych. Samo modelowanie struktury bazy danych odbywać się może w sposób podobny do modelowania obiektowego – przy wykorzystaniu notacji ERD lub UML. Narzędzia CASE dedykowane bazom danych dostarczają wielu funkcji ułatwiających budowę systemów bazodanowych. Często używaną grupą narzędzi są narzędzia do modelowania interfejsu użytkownika. Narzędzia takie pozwalają na tworzenie szkiców i makiet interfejsu użytkownika

Narzędzia implementacji i testowania

Praktycznie we wszystkich projektach używane są zintegrowane środowiska programistyczne (IDE). Podstawowymi elementami takich środowisk są inteligentny edytor kodu zintegrowany z kompilatorem oraz odpluskwiacz. Wiele nowoczesnych narzędzi klasy IDE posiada wsparcie dla prototypowania graficznych interfejsów użytkownika. Narzędzia IDE współpracują z narzędziami ciągłej integracji i wdrażania. Centrum takich systemów są mechanizmy automatycznego tworzenia i instalowania w środowisku wykonawczym, działających wersji rozwijanego produktu. Warsztat implementatora uzupełniają narzędzia do śledzenia błędów i problemów. Osobną grupę narzędzi stanowią systemy wspomagające testowanie. Wiele takich systemów pozwala na wspomaganie testów jednostkowych w ramach środowisk IDE. Inną grupę stanowią systemy wspomagające wykonywanie testów akceptacyjnych poprzez automatyzację nawigacji przez interfejs użytkownika.

Automatyzacja wytwarzania i eksploatacji

Kompletny cykl automatyzacji wytwarzania i eksploatacji oprogramowania obejmuje dwie podstawowe koncepcje: wytwarzanie oprogramowania sterowane modelami (WOSM) oraz DevOps. Podstawą WOSM jest automatyzacja procesu przekształcania modeli (analitycznych, projektowych) w inne, bardziej szczegółowe modele, oraz kod. Główną zasadą jest ujednolicenie definiowania składni języków za pomocą metamodeli oraz automatyzacja przetwarzania modeli jako grafów. Podejście DevOps koncentruje się przede wszystkim na dyscyplinach związanych z kodowaniem (implementacja, testowanie, wdrożenie i utrzymanie). Podstawową zasadą metody DevOps jest stworzenie spójnego zestawu narzędzi, które w jak największym stopniu zautomatyzują powtarzalne i rutynowe czynności w cyklu życia kodu. Co jest szczególnie istotne – nacisk jest położony na zintegrowanie czynności związanych z wytworzeniem oprogramowania (Dev - rozwój) z czynnościami związanych z eksploatacją (Ops - obsługa).