Programowanie z troską o jakość

W procesie produkcji oprogramowania wychodzimy z założenia, że dla klienta najważniejsza jest jakość oprogramowania. Jakość przekłada się bowiem zarówno i na koszty eksploatacji i na postrzeganie przedsiębiorstwa przez jego klientów. Wszystkie procesy po naszej stronie zostały tak zoptymalizowane, by to właśnie jakość stała na pierwszym miejscu.

Specjalizujemy się w systemach masowej przepustowości – przetwarzających gigantyczne ilości danych w krótkim czasie lub mniejsze ilości danych ale za to w ekstremalnie krótkim i często gwarantowanym czasie (np. systemy transakcyjne). Niektóre z tych rozwiązań – co całkiem naturalne -  funkcjonują w ogólnie rozumianym obszarze Big Data / Fast Data.

Biorąc pod rozwagę “jakość” oraz “systemy masowej przepustowości” szybko staje się jasne, że elementem ograniczającym jest zawsze czas produkcji systemu. Wyzwanie przed jakim więc stoimy to zapewnienie klientowi maksymalnej jakości systemu przetwarzającego masowe ilości danych – ale stworzonego i utrzymywanego w rozsądnym biznesowo czasie.

W produkcji naszych rozwiązań uwzględnić musimy również czas ich życia. Nasze systemy realizują najbardziej wymagające zadania – bywa, że i ponad 20 lat. Dlatego ważny jest nie tylko czas ich stworzenia ale nade wszystko koszt eksploatacji, łatwość rozbudowy, utrzymania, serwisu. Oznacza to, że system od samego początku musi być projektowany z myślą o wieloletnim, bezproblemowym użytkowaniu oraz o równie długim i stałym rozwoju.

To właśnie jakość systemu, konieczność zapewnienia niskich kosztów ciągłego rozwoju i utrzymania przy jednoczesnej minimalizacji czasu produkcji stoi za większością opisanych tu rozwiązań z zakresu inżynierii produkcji oprogramowania.

AGILE czy WATERFALL? - metodologia hybrydowa!Rozwiń

Produkując, wdrażając i utrzymując oprogramowanie korzystamy z hybrydowej metodologii czerpiącej najlepsze wzorce z czołowych światowych metodyk.

W procesie produkcji oprogramowania – szczególnie na etapie ofertowania – nie sposób odejść od klasycznego podejścia “waterfall” (analiza, projekt, implementacja, testy wdrożenie, utrzymanie). Podejście to stosowane jest w celu określenia szacunkowych kosztów przedsięwzięcia oraz ustaleniu jego harmonogramu. Wyznaczone w ten sposób wartości stanowią fundament późniejszych ustaleń odnosząc się głównie do kamieni milowych. Na etapie ofertowania ze względu na brak dokładnej analizy i projektu systemu (wykonywanych już w ramach realizacji umowy będącej skutkiem oferty) konieczne jest odwoływanie się uogólnień oraz arbitralne rozstrzyganie niejednoznaczności i niedopowiedzeń dostępnej w tym momencie dokumentacji.

Tym niemniej już na tym etapie zakładamy, że właściwa realizacja procesu w odniesieniu do kamieni milowych realizowana będzie za pomocą metodyk zwinnych (Agile).  Pozwala to naszemu klientowi na odstępstwa od rygoryzmu planów typu waterfall. Możliwe jest tworzenie, wdrażanie i utrzymanie systemu w sposób całkowicie elastyczny tak by uwzględniać zarówno zmieniające się otoczenie biznesowe, zmiany bezpośrednich wymagań funkcjonalnych jak i nawet zmiany budżetu i harmonogramu. Agile rozumiemy jako zwinność komunikacji z klientem pozwalającą na maksymalnie dokładne dopasowanie produktu/usługi do oczekiwań klienta i jego uwarunkowań w danym punkcie czasu.

Metodologie Agile idealnie też wpasowują się w nasze firmowe DNA: utrzymanie i rozwój aplikacji jest dla nas kluczowy – w niektórych przypadkach aplikacje utrzymujemy już od ponad 20 lat. Bez zwinnego podejścia byłoby to absolutnie niemożliwe.

Liderzy technologiczniRozwiń

Informatyka i technologia produkcji oprogramowania cały czas się rozwija. Trudno znaleźć inna dziedzinę wiedzy podlegającą tak radykalnym i tak szybkim zmianom. Jasne jest więc, że powinniśmy podążać za tymi technologiami. Ale jak to zrobić skoro technologie powstają – i większości po jakimś czasie zanikają – a tylko niewielka ich część na trwale zmienia oblicze branży IT? Jak pogodzić to z wymaganiami klientów, którzy oczekują w procesie produkcji oprogramowania stosowania wiarygodnych i stabilnych rozwiązań i metod?

Dlatego w naszej firmie stosujemy macierzową strukturę zarządzania. Niezależnie od typowej hierarchii wprowadziliśmy poziomy technologiczne. Takim poziomem jest w szczególności interfejs użytkownika, reguły biznesowe, baza danych ale też np. nasza platforma mikrousług Atom. Każdy z takich poziomów posiada swojego lidera. Lider jest odpowiedzialny za wyszukiwanie oraz ewaluację pojawiających się na jego poziomie technologii. Lider decyduje o ich implementacji w firmie oraz kieruje sposobem ich wykorzystania – definiuje na bieżąco tzw. zestaw dobry praktyk dla nadzorowanego przez siebie obszaru. Oznacza to, że każdy deweloper korzysta jedynie z zatwierdzonych technologii a sposób ich użycia jest starannie nadzorowany i kontrolowany. Nawet upgrade wersji danej technologii podlega ocenie Lidera.

Lider jest niezwykle starannie dobierany – jest to osoba z największym na danym poziomie zasobem wiedzy. Mimo tego jego kluczowym zadaniem jest wszakże stała rozbudowana tej wiedzy i bieżące monitorowanie rynku – zarówno w odniesieniu do jego komercyjnej części jak i projektów open-source – tak by na bieżąco mieć pełny przegląd możliwości dostępnych w danym momencie.

Mikrousługi - Platforma AtomRozwiń

Fundamentem naszego podejścia do budowy oprogramowania i to już od ponad 20 lat – są mikrousługi. Tę metodologię stosowaliśmy w czasach kiedy nie miała ona jeszcze swojej nazwy. Musieliśmy więc stworzyć własne rozwiązanie w tym obszarze. Dziś – po ponad 20 latach rozwoju – jesteśmy dumni, że kierunek jaki obraliśmy stał się jednym z wiodących kierunków rozwoju dzisiejszej informatyki.

Od początku konsekwentnie rozwijamy platformę PTR “Atom” dającą niezrównane możliwości uruchamiania zarówno dziesiątek jak i setek tysięcy mikrousług.

Platforma Atom:

  • radykalnie przyspiesza dewelopment przez możliwość urównoleglenia pracy programistów
  • radykalnie ułatwia testowanie mikrousług
  • pozwala na łatwe i elastyczne budowanie złożonych i kompleksowych usług (“związków chemicznych”) z prostych i jasno zdefiniowanych  mikrousług (“atomów”)
  • posiada wbudowane mechanizmy klastrowania, monitoringu, SLA, COB, mechanizmy bezpieczeństwa itd.
  • może działać w sposób zupełnie automatyczny w trybie unattended (“bez nadzoru”)

DevOpsRozwiń

Ze względu na dość częste tworzenie oprogramowania w modelu outsourcingowym (kiedy zarówno dewelopment jak i późniejsza obsługa systemu leżą po naszej stronie) praktycznie zawsze stosujemy mechanizmy DevOps. Oznacza to w naszym przypadku:

1. Kodowanie oparte o najlepsze sprawdzone rozwiązania i technologie. Stosowanie systemów kontroli wersji (GitLab) zarówno w odniesieniu do kodu aplikacji jak i do bazy danych.

Jest to o tyle istotne, że w systemach masowej przepustowości warstwa bazodanowa jest budowana szczególnie starannie tak by zapewnić maksymalną wydajność oraz (co często jest jeszcze istotniejsze) maksymalną skalowalność. System kontroli wersji musi więc kontrolować również wersje kodu i struktury samej bazy danych

Stosujemy code review – w kluczowych elementach kodu. Jest to z jednej strony realizowane w zespole deweloperskim – ale dysponujemy też samodzielną komórką odpowiedzialną tylko za utrzymanie właściwej jakości kodu. Komórka ta odpowiedzialna jest również za kontrolę całego kodu wszystkich nowych pracowników na etapie ich adaptacji.

Konfiguracja systemu kontroli wersji oraz procedury “merge” pozwalają nam z jednej strony na niezakłócony rozwój aplikacji a z drugiej strony na bieżące realizowanie obowiązków związanych z usuwaniem błędów.

2. Continuous Building – w naszym środowisku stworzony kod źródłowy jest poddawany procesowi budowania – zarówno w kontekście artefaktów jak i samej aplikacji. Wewnętrznie, w trakcie produkcji oprogramowania, stosujemy aplikacje w wersji skonteneryzowanej. Dlatego po zbudowaniu aplikacji następuje wykreowanie obrazu kontenera(-ów) Docker oraz stworzenie pełnego środowiska w oparciu o orchestrację Kubernetes.

3. Continuous Testing – na tak stworzonym środowisku uruchamiane są mechanizmy testów automatycznych. Z jednej strony oznacza to automatyzację unit testów ale z drugiej strony są to też klasyczne testy API czy interfejsu użytkownika. Celem testów automatycznych (tworzonych przez niezależny zespół) jest realizacja zarówno testów regresji (w odniesieniu do funkcjonalności z poprzednich sprintów) jak i testów bieżącego sprinta. Co ważne – testy te realizowane są jeszcze przed skierowaniem systemu do działu testów manualnych. W efekcie potrafimy się zabezpieczyć przed zmorą wielu wdrożeń – nawracającymi błędami  pojawiającymi się podczas naprawy innych błędów.

4. Packaging/Delivery – ze względu na stosowanie konteneryzacji – wszystkie nasze rozwiązania przygotowane są jako gotowe kontenery – możliwe do pobrania przez klienta bezpośrednio z naszego wewnętrznego repozytorium. Proces aktualizacji oprogramowania staje się więc szczególnie prosty. Nawet w przypadku klientów, którzy jeszcze nie wdrożyli konteneryzacji – procesy Delivery znacząco się upraszczają.

5. Konfiguracja – ze względu na stosowanie Kubernetes (a w razie potrzeby narzędzi klasy infrastructure-as-a-code) przygotowana aplikacja jest w pełni skonfigurowana jako działający zestaw niezbędnych serwerów powiązanych z sobą. W typowym przypadku wdrożenie nowego sprinta polega u klienta na banalnej operacji odświeżenia obrazów kontenerów i ponownym uruchomieniu orchestracji Kubernetes.

6. Monitoring – tak uruchomiona aplikacja podlega ciągłemu procesowi monitoringu. Jest to szczególnie istotne w kontekście zapewnienia odpowiedniego poziomu SLA w zakresie usuwania błędów.

Ergonomia oprogramowaniaRozwiń

Użyteczność i niezawodność oprogramowania to jednak nie wszystko – dzisiejsze aplikacje powinny być także funkcjonalne, intuicyjne i ergonomiczne, dopasowane do cech użytkownika.

Dzięki wykorzystaniu metodyk projektowania zorientowanych na użytkownika oraz nowoczesnych narzędzi do budowy aplikacji WWW tworzymy dla klientów wyrafinowane, dynamiczne, w pełni interaktywne interfejsy użytkownika na najwyższym poziomie, zarazem funkcjonalne i przyjazne. Co więcej możemy budować takie aplikacje nie tylko widoczne dla przeglądarek w komputerach PC, ale również dla tabletów i innych urządzeń mobilnych. Jest to związane z tendencją jaką zauważamy by zamiast budować aplikacje mobilne sensu stricte – budować uniwersalne wersje stron WWW widoczne w specjalny sposób na urządzeniach przenośnych.

Testy - nasza idea 'Bahaviour-Driven Relation'Rozwiń

W celu zapewnienia odpowiedniej jakości oprogramowania testy wykonywane są w naszym oprogramowaniu na wielu poziomach:

  • jako unit testy – tworzone bezpośrednio przez programistów w odniesieniu do wszystkich trzech warstw aplikacji
  • jako testy manualne – realizowane przez Dział Testów Manualnych
  • jako testy automatyczne  – realizowane przez Dział Testów Automatycznych a przekazywane do Działu Deweloperskiego

Mechanizm tzw. unit testów oznacza, że wszystkie nasze aplikacje są wyposażone w specjalizowane funkcje testujące poprawność pojedynczych małych jednostek oprogramowania. Dla każdego zlecenia programiści tworzą specjalne procedury testowe, które następnie są wykonywane w sposób całkowicie automatyczny. W efekcie osiągnęliśmy zdecydowaną poprawę jakości oprogramowania poprzez automatyzację testów regresji – sprawdzenie czy błąd jaki już kiedyś występował i został naprawiony – nie pojawił się ponownie.

Stosując mechanizm testów bazy danych automatyczne badamy jakość procedur składowanych w bazie danych. Procedury te stanowią fundament na którym budowana jest reszta aplikacji – dlatego używamy narzędzi które w sposób zautomatyzowany są w stanie przeprowadzić gigantyczną liczbę testów i zbadać poprawności wykonania procedur składowanych, nawet przy najdrobniejszych zmianach. Testy na tym poziomie można rozumieć jako testy warstwy bazy danych w klasycznej trójwarstwowej architekturze aplikacji.

Dopełnieniem procesu testów jest mechanizm testowania interfejsów programistycznych do aplikacji (REST). Oznacza to, że nim przeprowadzimy testy interfejsu użytkownika automatycznie sprawdzamy poprawność interfejsów programistycznych (wywołujących procedury składowane i wykorzystujących unity aplikacji testowane na poziomie unit testów). Testy na tym poziomie można rozumieć jako testy warstwy biznesowej.

Powyższe mechanizmy testów łączymy z testami intrerfejsu użytkownika dla aplikacji WWW wykonywanymi przez dział testów wykorzystujący w tym celu m.in. oprogramowanie Selenium/Katalon będące zestawem narzędzi służących do zapisywania scenariuszy testowych a następnie ich automatycznego wykonywania przy każdej najdrobniejszej modyfikacji aplikacji, nawet jeśli z pozoru dana modyfikacja wydaje się nie mieć jakiegokolwiek związku z innymi elementami aplikacji.

Wdrożyliśmy rozwiązanie pozwalające na automatyczne wykonywanie nie tylko procesu budowania aplikacji z przygotowanych przez programistów kodów źródłowych, ale nade wszystko na automatyczne wykonanie wszystkich testów powyżej (Continuous integration).

Celem jest aby każda kolejna – nawet minimalna poprawka dowolnego fragmentu kodu źródłowego aplikacji powodowała automatyczne wykonanie wszystkich automatycznych testów: testów jednostkowych, testów bazy danych (procedur składowanych), testów warstwy biznesowej  i testów interfejsu użytkownika.

Testy powyższe, w zależności od swojego położenia w procesie, mogą w szczególności stanowić testy regresji (poprzez test w danym sprincie realizacji funkcjonalności już zrealizowanych w sprintach poprzednich), testy akceptacyjne – lub dowolny inny rodzaj testów.

W celu zapewnienia maksymalnej jakości oprogramowania Dział Deweloperski, Testów Manualnych oraz Dział Testów Automatycznych są niezależne od siebie. Współdzielone są natomiast scenariusze testowe – tak by zapewnić maksymalnie pokrycie aplikacji testami. Scenariusze testowe są ściśle zdefiniowane. Dzięki temu wszystkie wspomniane zespoły mogą efektywnie wpływać na jakość finalnej aplikacji.

Testy, ze względu na oczekiwaną wysoką jakość oprogramowania, stanowią centralny element całego procesu. Wychodząc z metodologii TDD (Test Driven Development) stosujemy zmodyfikowane BDD (Behaviour Driven Development). “Zmodyfikowane” bo uważamy, że nie jedynie sam proces wytwórczy oprogramowania powinien być podporządkowany oczekiwanemu zachowaniu systemu. Naszym zdaniem wszystkie procesy wiążące dostawcę oprogramowania z klientem powinny być temu podporządkowana

Dlatego wolimy mówić o Behaviour Driven Relation (BDR).

W BDR zakładamy, że całość relacji pomiędzy nami – jako dostawcą – a klientem powinna skupiać się na konkretnych oczekiwanych przez klienta funkcjonalnościach/zachowaniach aplikacji. Co więcej – wymagania te powinny być sformułowane w najbardziej zrozumiałym dla niego języku biznesowym. Stanowi to czytelne odniesienie do wizji DDD (Domain Driven Design).

Z wieloletniego doświadczenia wynika, że zazwyczaj klientowi zdecydowanie łatwiej przychodzi opisanie konkretnych przykładów działania aplikacji niż zdefiniowanie jej dokładnego funkcjonowania jak się to dzieje w “klasycznej” analizie. Takie przykłady działania systemu z jednej strony mogą stanowić doskonały wsad do produkcji oprogramowania, specyfikację testu (manualnego czy automatycznego), a nawet mogą stanowić rewelacyjne uzupełnienie dokumentacji (gdyż stworzone są w języku i przy pomocy pojęć zrozumiałych dla klienta).

Powyższe oznacza, że już na etapie specyfikowania wymagań danego systemu, czy też węziej – kamienia milowego, sprinta czy wręcz pojedynczej funkcjonalności – określamy zachowanie się systemu – np. za pomocą notacji Gherkin. Świadomość jak powinna zachowywać się aplikacja – już na etapie analizy/projektu – zupełnie inaczej ustawia cały proces przeprowadzania rozmów i ustaleń z klientem. Radykalnie zmienia to relację z nim – rozmowy dotyczą nie tyle pojedynczej dostawy – co konkretnej funkcjonalności, konkretnego zachowania jakiego z biznesowego punktu widzenia klient oczekuje. Rozmowy te prowadzone są nie tylko w typowym dla inżynierii oprogramowania języku opartym o “deliverables”, “sprinty”, “backlog” ale nade wszystko w języku opisującym konkretne efekty jakie klient chce osiągnąć przy pomocy aplikacji.

Efektem tego jest zmiana typowej relacji dostawca-odbiorca w relacje partnerska w której obie strony skupiają się na zachowaniu systemu a tym samym jego jakość stawiana jest na pierwszym miejscu w liście priorytetów.

Koordynacja prac i wymiana wiedzy, SLARozwiń

W celu zapewnienia właściwej koordynacji prac – przy mnogości spraw realizowanych w każdym projekcie – od wielu lat konsekwentnie stosujemy rozwiązania światowego lidera – firmy Atlassian:

  • Jira – jest naszym kluczowym systemem do definiowania zleceń, kontroli procesu realizacji, nadzoru nad właściwym workflow, definiowania wymagań a nawet do komunikacji z klientem na etapie zgłaszania uwag i rozwoju systemu. Jira służy nam do kompleksowego  zarządzania projektami, umożliwiając nam jednocześnie terminową realizację poszczególnych zleceń o najwyższej jakości
  • Confluence – jest naszym kluczowym system do tworzenia, przechowywania i udostępniania wiedzy. Dotyczy to zarówno wiedzy na temat danego systemu (tak tworzymy i aktualizujemy różnego rodzaju dokumentacje) jak i wiedzy operacyjnej (procedury współpracy, wewnętrzne regulacje itd). Jest to specjalizowany collaboration serwer za pomocą którego grupy projektowe mogą tworzyć i współdzielić dokumentacje, wymieniać się pomysłami oraz wiedzą. Efektem wdrożenia jest wewnętrzny portal służący do przechowywania dokumentacji oraz wymiany wiedzy w związku z realizacją konkretnych zleceń dla klientów z dokładnością do pojedynczej sprawy i jej historii.

Oba narzędzia uzupełnione są zestawem pluginów uzupełniających funkcjonalność o niezbędne elementy (np. rozliczanie czasu pracy, definiowanie testów itp.)

  • Chcąc zapewnić naszym Klientom transparentność oraz najwyższą jakość obsługi serwisowej udostępniamy, zintegrowany z Jira, niezwykle intuicyjny internetowy system ticketowy dmt@work, który umożliwia nie tylko rejestrację i śledzenie realizacji danego zlecenia lecz także dwustronną wymianę informacjami, spostrzeżeń i uwag związanych z daną sprawą na dowolnym z etapie jej realizacji. dmt@work spełnia zatem w naszej firmie rolę interaktywnej i dynamicznej platformy do codziennej współpracy oraz przepływu informacji pomiędzy zespołem dmt a naszym Klientem.

 

Wróć do góry