EA - Wstęp do Behavior Driven Development (BDD)

 Współczesne metodyki tworzenia oprogramowania coraz częściej koncentrują się na współpracy między zespołami technicznymi a biznesowymi. Jednym z najskuteczniejszych podejść, które to umożliwiają, jest Behavior Driven Development (BDD). Dzięki BDD zespoły mogą efektywnie komunikować się i precyzyjnie definiować wymagania, co prowadzi do tworzenia bardziej użytecznych i spójnych systemów.

W tym artykule przedstawię, czym jest BDD, jak działają narzędzia takie jak Cucumber i język Gherkin, oraz jak za pomocą narzędzia CuPL można generować scenariusze BDD na podstawie diagramów aktywności generowanych w PlantUML.

Behavior Driven Development (BDD) – czym jest?

BDD to praktyka, która umożliwia zespołom programistycznym i biznesowym współpracę przy definiowaniu zachowania systemu. Podejście to opiera się na scenariuszach, które opisują, jak system powinien działać w różnych sytuacjach. Kluczowe cechy BDD:

1. Wspólny język: Wszystkie strony zaangażowane w projekt mogą zrozumieć scenariusze, ponieważ są pisane w prostym, naturalnym języku.
2. Testy jako dokumentacja: Scenariusze stają się żywą dokumentacją, która jest zawsze zgodna z implementacją.
3. Automatyzacja: Narzędzia takie jak Cucumber pozwalają na automatyczne uruchamianie scenariuszy jako testów.

---

Narzędzie Cucumber i język Gherkin

Cucumber

Cucumber to popularne narzędzie wspierające BDD. Pozwala na definiowanie zachowania systemu w formie scenariuszy testowych i automatyczne ich uruchamianie. Główne cechy:

• Obsługa wielu języków programowania, w tym Java, Python, Ruby i JavaScript.
• Integracja z frameworkami testowymi, takimi jak JUnit czy TestNG.
• Możliwość łączenia scenariuszy z kodem za pomocą tzw. step definitions.

Gherkin

Język Gherkin to rdzeń Cucumbera. Służy do pisania scenariuszy w sposób czytelny zarówno dla programistów, jak i interesariuszy biznesowych. Struktura scenariuszy opiera się na kilku kluczowych słowach kluczowych:

• Feature: Opis funkcjonalności, która ma być zaimplementowana.
• Scenario: Konkretna sytuacja testowa.
• Given: Warunki początkowe.
• When: Akcja wykonywana w systemie.
• Then: Oczekiwane rezultaty.

Przykład scenariusza w Gherkin

Feature: Logowanie użytkownika
  Scenario: Poprawne logowanie
    Given użytkownik jest na stronie logowania
    When wpisze poprawne dane logowania
    Then zostanie przekierowany na stronę główną

Scenariusze te są następnie mapowane na step definitions – fragmenty kodu, które wykonują konkretne akcje.

CuPL

Ciekawym narzędziem jest CuPL -  CLI do automatycznego generowania plików feature Cucumber Gherkin z diagramu aktywności PLantuml

CuPL pozwala nie tylko przekształcać diagramy PlantUML w scenariusze Gherkin, ale również dostosowywać scenariusze za pomocą pliku konfiguracyjnego .cupl.json. Dzięki temu proces tworzenia testów BDD staje się bardziej precyzyjny i dostosowany do potrzeb projektu. 

Generowanie wstępnego scenariusza Gherkin

Uruchom CuPL, aby wygenerować podstawowy plik .feature oraz plik konfiguracyjny .cupl.json:

npx cupl atm.puml

Po uruchomieniu otrzymasz:

• Plik atm.feature: Wstępny scenariusz Gherkin.
• Plik atm.cupl.json: Plik konfiguracyjny do dostosowania scenariuszy.

Dostosowanie scenariuszy za pomocą .cupl.json

Otwórz wygenerowany plik .cupl.json i dostosuj go do swoich potrzeb. Przykład konfiguracji:

{
  "$schema": "https://raw.githubusercontent.com/cinoss/cupl/master/src/config.schema.json",
  "global": {
    "alias": {
      "PIN is correct": "User enters the correct PIN",
      "PIN is incorrect": "User enters an incorrect PIN"
    },
    "dialect": "en"
  },
  "paths": {
    "PIN is correct|Balance is sufficient": {
      "name": "Successful transaction"
    },
    "PIN is correct|Insufficient balance": {
      "name": "Insufficient funds",
      "tags": ["important"]
    },
    "PIN is incorrect": {
      "alias": {
        "enter PIN": "User provides PIN <input>"
      },
      "examples": [
        ["input"],
        ["1234"],
        ["0000"]
      ]
    }
  }
}

Co możesz zrobić w .cupl.json?

• Zmiana nazw scenariuszy: Użyj pola name w sekcji paths, aby nadać sensowne nazwy.
• Aliasowanie kroków: Użyj alias, aby zmienić nazwy kroków.
• Dodawanie tagów: Dodaj tags, aby oznaczyć scenariusze specjalnymi etykietami.
• Dodawanie przykładów: Użyj examples, aby zdefiniować parametry w krokach scenariuszy.
• Zmiana języka: Pole dialect umożliwia ustawienie innego języka Gherkin.

Generowanie ostatecznego scenariusza Gherkin

Po wprowadzeniu zmian w .cupl.json, uruchom CuPL ponownie z flagą -w, aby wygenerować zaktualizowany plik .feature:

npx cupl -w atm.puml

Wygenerowany plik .feature będzie dostosowany zgodnie z ustawieniami w .cupl.json.

Przykład wygenerowanego scenariusza

Plik .feature po dostosowaniu

Feature: ATM Transactions

  Scenario: Successful transaction
    Given User enters the correct PIN
    When Balance is sufficient
    Then Dispense Cash

  Scenario: Insufficient funds @important
    Given User enters the correct PIN
    When Insufficient balance
    Then Show Error

  Scenario Outline: Invalid PIN
    Given User provides PIN <input>
    Then Retry

    Examples:
      | input  |
      | 1234   |
      | 0000   |

Podsumowanie

BDD to podejście, które łączy techniczne i biznesowe aspekty tworzenia oprogramowania. Dzięki narzędziom takim jak Cucumber, Gherkin i CuPL, zespoły mogą tworzyć czytelne scenariusze, które są jednocześnie testami, dokumentacją i mogą mieć swój początek z diagramów aktywności.

Jeśli chcesz usprawnić współpracę w zespole, poprawić jakość kodu i tworzyć bardziej zrozumiałe systemy, wypróbuj BDD w połączeniu z narzędziami do automatyzacji i wizualizacji. Behavior Driven Development to nie tylko metoda, ale i sposób myślenia o współczesnym tworzeniu oprogramowania.

dev{properties}: Komunikacja... z AI

 W poprzednim wpisie „Dev{properties}: Komunikacja” omawiałem, jak ważna jest skuteczna wymiana informacji między ludźmi. Dziś chciałbym rozwinąć ten temat, skupiając się na komunikacji z AI, która coraz częściej staje się integralnym elementem naszego codziennego życia i pracy.

Komunikacja z AI, podobnie jak z ludźmi, wymaga jasności, precyzji i dostosowania. Aby maksymalnie wykorzystać możliwości narzędzi opartych na sztucznej inteligencji, warto poznać techniki skutecznego tworzenia promptów, czyli poleceń dla AI.

Dlaczego komunikacja z AI jest kluczowa?

AI działa na podstawie danych wejściowych, które dostarczamy. Jakość tych danych – czyli sposobu, w jaki formułujemy nasze zapytania – ma bezpośredni wpływ na otrzymywane wyniki. Dobrze sformułowany prompt pozwala osiągnąć precyzyjne, trafne i użyteczne odpowiedzi, podczas gdy chaotyczne lub niejasne zapytania prowadzą do niezadowalających rezultatów.

Techniki efektywnego tworzenia promptów

Oto kilka skutecznych technik, które pomogą Ci w komunikacji z AI:

1. Użycie kontekstu

Zapewnienie AI odpowiedniego kontekstu znacząco poprawia jakość odpowiedzi. Przykład:

• Zamiast: „Opisz NFRy.”
• Lepszy prompt: „Opisz, czym są NFRy w kontekście zarządzania projektami IT i podaj przykłady wymagań dotyczących wydajności i bezpieczeństwa.”

2. Precyzyjne instrukcje

Określenie, jak ma wyglądać wynik, pozwala uniknąć niejasnych odpowiedzi:

• Zamiast: „Przygotuj artykuł o komunikacji z AI.”
• Lepszy prompt: „Napisz artykuł o komunikacji z AI, uwzględniając techniki tworzenia promptów, z konkretnymi przykładami i odniesieniem do wcześniejszych wpisów blogowych.”

3. Podział na kroki

Rozbijanie skomplikowanych zapytań na mniejsze części pomaga AI zrozumieć Twoje oczekiwania:

• „1. Opisz, czym są drivery architektoniczne. 2. Wyjaśnij, jak NFRy wpisują się w drivery. 3. Podaj przykłady zarządzania nimi w czasie projektu.”

4. Wykorzystanie formy role-play

AI działa lepiej, gdy „wcieli się” w określoną rolę. Przykład:

• „Jesteś ekspertem w zarządzaniu projektami IT. Wyjaśnij, czym są NFRy i jak wpływają na sukces projektów.”

5. Tworzenie formatowanych wyników

Jeśli potrzebujesz wyników w określonym formacie, poinformuj AI:

• „Stwórz listę punktowaną z głównymi cechami i przykładami NFRów w projektach IT.”

6. Iteracyjny prompting

Nie bój się zadawać kolejnych pytań, aby doprecyzować wynik. Przykład:

• „Rozwiń drugi punkt dotyczący wydajności w NFRach.”
• „Podaj przykłady narzędzi do testowania wydajności, które wspierają realizację wymagań.”

Jak AI wpisuje się w naszą codzienną komunikację?

Podobnie jak w komunikacji między ludźmi, ważne jest wzajemne zrozumienie i dostosowanie. AI nie jest doskonała, ale odpowiednio „prowadząc” ją za pomocą przemyślanych promptów, możemy uzyskać użyteczne odpowiedzi, które wspierają naszą pracę i procesy decyzyjne.

Porównanie komunikacji człowiek-AI do komunikacji międzyludzkiej

Komunikacja z AI, podobnie jak z ludźmi, wymaga:

1. Jasności – precyzyjnie sformułowane cele i oczekiwania.
2. Kontekstu – dostarczania odpowiednich informacji, aby odbiorca (człowiek lub AI) mógł lepiej zrozumieć sytuację.
3. Cierpliwości – iteracyjne poprawianie i doprecyzowywanie dialogu.

Tak jak w komunikacji międzyludzkiej, skuteczna wymiana informacji z AI opiera się na wzajemnym dostosowaniu. Im bardziej zrozumiałe są nasze potrzeby, tym trafniejsze będą odpowiedzi. W końcu, zarówno w relacjach międzyludzkich, jak i w relacji człowiek-AI, kluczowe jest jedno – dialog oparty na współpracy i wzajemnym zrozumieniu.

EA - PlantUML: Automatyzacja i Wizualizacja Twojej Architektury

Diagramy i wizualizacje to podstawa zrozumienia skomplikowanych systemów. PlantUML to narzędzie, które pozwala generować je automatycznie na podstawie prostego tekstowego opisu. Dzięki niemu możesz:

• Zautomatyzować proces tworzenia diagramów, eliminując czasochłonne ręczne rysowanie,
• Łatwo utrzymać ich aktualność w dynamicznych projektach, gdzie zmiany w kodzie mogą automatycznie odzwierciedlać się w diagramach,
• Zintegrować wizualizacje z dokumentacją i pipeline’ami CI/CD, zgodnie z filozofią Documentation as Code, którą szczegółowo omówiłem tutaj.

Najważniejsze diagramy, które możesz generować za pomocą PlantUML

PlantUML wspiera szeroką gamę diagramów, które mogą być wykorzystane w różnych fazach projektu IT:

1. Diagramy UML (Unified Modeling Language):

   • Diagramy klas – pokazujące relacje między klasami w systemie.
   • Diagramy sekwencji – obrazujące przepływ komunikacji między komponentami.
   • Diagramy przypadków użycia – opisujące interakcje użytkowników z systemem.
   • Diagramy komponentów – przedstawiające strukturę systemu pod kątem komponentów i zależności między nimi.

2. Diagramy architektury:

   • Diagramy C4 – pomocne w modelowaniu systemów na poziomie koncepcyjnym, kontenerów i komponentów, zgodnie z podejściem Structurizr.
   • Diagramy wdrożeniowe – prezentujące sposób rozmieszczenia systemu na infrastrukturze.

3. Specjalne diagramy wspierające zarządzanie projektami:

   • Diagramy Gantta – obrazujące harmonogram projektu i zależności między zadaniami (więcej na ten temat tutaj).
   • Diagramy przepływu pracy (WBS) – diagram, który pomaga organizować i definiować zadania w projekcieci.

4. Diagramy interfejsów:

   • Wireframe (Salt) – pomocne w projektowaniu graficznych interfejsów użytkownika.

Zastosowanie PlantUML w dokumentacji jako kod

Dzięki integracji z narzędziami takimi jak Asciidoctor, Structurizr czy platformami CI/CD, diagramy generowane w PlantUML mogą stać się integralną częścią Twojej dokumentacji. Dokumentacja nie tylko pozostaje zawsze aktualna, ale także jest automatycznie generowana, co idealnie wpisuje się w zasady Documentation as Code.

Ciekawostka – Diagram Gantta i Wireframe (Salt)

PlantUML pozwala na generowanie nietypowych diagramów, które wspierają nie tylko architekturę, ale również zarządzanie projektami i projektowanie interfejsów:

• Diagram Gantta – umożliwia wizualizację harmonogramów projektowych, z zadaniami, ich zależnościami i czasem trwania.
• Wireframe (Salt) – doskonały do prototypowania interfejsów użytkownika, pozwalając na szybkie tworzenie szkiców graficznych.

Dlaczego warto wybrać PlantUML?

PlantUML to narzędzie, które z powodzeniem konkuruje z komercyjnymi rozwiązaniami do wizualizacji i dokumentacji. Dzięki możliwości integracji z popularnymi narzędziami oraz otwartoźródłowemu charakterowi, jest doskonałym wyborem zarówno dla małych zespołów, jak i dużych organizacji. Omówiłem te aspekty szczegółowo w artykule „EA: Narzędzia i technologie”.

Zapraszam do kontaktu i rezerwacji terminów na warsztaty oraz konsultacje. Razem usprawnimy Twoje procesy dokumentacyjne i architektoniczne!

EA - NFR (Non-Functional Requirements): Kluczowe aspekty zarządzania i kategoryzacji

 Wymagania niefunkcjonalne (ang. Non-Functional Requirements, NFRs) to krytyczny element każdego projektu IT. Choć często stoją w cieniu wymagań funkcjonalnych, NFRy determinują jakość, wydajność, bezpieczeństwo i użyteczność systemu. Są one kluczową częścią tzw. driverów architektonicznych, które wpływają na wybory technologiczne i architektoniczne.

Czym są NFRy?

NFRy określają, jak system powinien działać, a nie co ma robić. Nie definiują funkcjonalności systemu, ale jego cechy, takie jak:

• Wydajność: czas odpowiedzi API, obsługa dużej liczby użytkowników.
• Bezpieczeństwo: brak podatności o wysokim ryzyku w testach OWASP ZAP.
• Dostępność: procentowy czas dostępności systemu zgodny z SLA.
• Kompatybilność: zgodność z określonymi przeglądarkami, urządzeniami i systemami operacyjnymi.
• Użyteczność: maksymalny akceptowalny procent błędów użytkownika.

NFRy jako część driverów architektonicznych

Definicja driverów

Driver to uzasadnienie wyboru określonego rozwiązania – technologii, architektury lub sposobu implementacji. Drivery pomagają zrozumieć priorytety interesariuszy i dostosować system do ich oczekiwań.

Typy driverów:

1. Wymagania funkcjonalne: lista funkcji, które system ma realizować.
2. Atrybuty jakościowe (NFRy): np. wydajność, bezpieczeństwo, skalowalność.
3. Ograniczenia projektowe: czas, budżet, zasoby, dostępne technologie.
4. Konwencje: zasady stosowane w celu zachowania spójności i wartości.
5. Cele projektowe: np. prototyp, produkcyjne rozwiązanie, projekt badawczy.

Kategoryzacja NFRów

1. Wydajność (Performance):

• Strona internetowa musi obsłużyć określoną liczbę użytkowników w czasie godzinowym przy zachowaniu maksymalnego czasu odpowiedzi poniżej np. 2 sekund.
• API musi odpowiadać w czasie nieprzekraczającym 300 ms na żądanie.

2. Kompatybilność (Compatibility):

• System musi działać na określonych wersjach systemów operacyjnych, przeglądarek i urządzeń.
• Wymagania sieciowe: kompatybilność z LTE oraz 5G.

3. Dostępność (Availability):

• Usługa musi być dostępna 99,9% czasu w miesiącu zgodnie z SLA.

4. Bezpieczeństwo (Security):

• Strona i API nie mogą posiadać wysokich ani średnich podatności według raportu OWASP ZAP.

5. Lokalizacja (Localization):

• System musi wspierać lokalne formaty walut, dat i adresów w określonych regionach.

6. Użyteczność (Usability):

• Maksymalny akceptowalny procent błędów użytkownika nie może przekraczać 0,5%.

Jak zarządzać NFRami w czasie projektu?

1. Odkrywanie NFRów:

   • NFRy należy zidentyfikować na etapie analizy wymagań poprzez rozmowy z interesariuszami.
   • Warto korzystać z narzędzi takich jak stakeholder mapping, aby zrozumieć priorytety i oczekiwania użytkowników.

2. Priorytetyzacja:

   • Nie wszystkie NFRy mają jednakowe znaczenie. Kluczowe jest ustalenie, które z nich są krytyczne dla sukcesu projektu.
   • Przykład: W systemie płatności online bezpieczeństwo będzie ważniejsze niż wydajność.

3. Zarządzanie zmianami:

   • Drivery, w tym NFRy, zmieniają się w trakcie cyklu życia projektu. Ważne jest ich regularne przeglądanie i aktualizowanie.

4. Monitorowanie i testowanie:

   • NFRy powinny być mierzalne i testowalne. Na przykład:
     • Wydajność API można testować za pomocą narzędzi takich jak Postman czy JMeter.
     • Bezpieczeństwo systemu można monitorować za pomocą OWASP ZAP.
   • Regularne testy pozwalają upewnić się, że system spełnia określone wymagania.

5. Automatyzacja:

   • Wprowadzenie testów NFR w pipeline CI/CD pozwala na bieżące weryfikowanie, czy wprowadzane zmiany spełniają wymagania.

Przykład zastosowania NFRów w projekcie

Załóżmy, że tworzysz platformę e-commerce. Oto, jak można zarządzać NFRami:

1. Wydajność: Strona główna musi ładować się w czasie poniżej 3 sekund, obsługując 1000 użytkowników jednocześnie.
2. Bezpieczeństwo: Wszystkie formularze płatności muszą przechodzić testy OWASP ZAP bez ostrzeżeń o wysokim ryzyku.
3. Dostępność: System musi być dostępny 99,9% czasu w miesiącu, z wyjątkiem zaplanowanych przerw serwisowych.
4. Lokalizacja: Ceny produktów muszą być wyświetlane w walucie użytkownika, zgodnie z jego lokalizacją.

Podsumowanie

NFRy są nieodłącznym elementem driverów architektonicznych i mają kluczowy wpływ na sukces projektu. Poprawne ich zidentyfikowanie, kategoryzacja i zarządzanie pozwalają na budowanie systemów, które nie tylko realizują funkcjonalności, ale także spełniają wymagania jakościowe, bezpieczeństwa i wydajności. Dzięki systematycznemu podejściu i automatyzacji procesów testowania NFRy mogą stać się fundamentem efektywnego zarządzania projektem IT.

EA - Dokumentacja Nie Musi Być Nudna: Wprowadzenie do Documentation as Code"

    Czy tworzenie dokumentacji mus być nudnym i najczęściej pomijanym obowiązkiem? Większość z nas tak to widzi. Ale co, jeśli powiem Ci, że może stać się integralną częścią Twojego workflow, dynamiczną, w pełni zautomatyzowaną i dostosowaną do potrzeb zespołu? Takie podejście jest możliwe dzięki filozofii Documentation as Code (Docs as Code), którą omówiłem w artykule „Dokumentacja jako Kod”.

Czym jest Documentation as Code?

Docs as Code to podejście, które traktuje dokumentację w taki sam sposób, jak kod źródłowy aplikacji. Oznacza to, że:

• Dokumentacja znajduje się w tych samych repozytoriach co kod.
• Wykorzystuje się narzędzia takie jak Git do wersjonowania i wspólnej pracy.
• Proces tworzenia i aktualizacji dokumentacji jest zintegrowany z pipeline CI/CD.

Tym samym dokumentacja przestaje być statycznym artefaktem, a staje się dynamicznym elementem Twojego projektu, który może być automatycznie generowany i aktualizowany.

Zalety podejścia Docs as Code

1. Automatyzacja Dzięki narzędziom takim jak PlantUML, Structurizr, czy arc42, możesz generować dokumentację bezpośrednio z kodu i repozytoriów. Na przykład:

   • Modele UML mogą być automatycznie tworzone na podstawie kodu źródłowego.
   • Struktura systemu generowana z plików DSL, takich jak Structurizr DSL.

   Automatyzacja eliminuje ręczne pisanie dokumentacji i pozwala skupić się na tworzeniu oprogramowania.

2. Integracja z CI/CD Dokumentacja może być automatycznie aktualizowana za każdym razem, gdy kod zmienia się w repozytorium. W pipeline CI/CD możesz dodać kroki takie jak:

   • Generowanie modeli i diagramów.
   • Publikacja dokumentacji na wewnętrznych portalach lub w serwisach takich jak GitHub Pages.
   • Automatyczne sprawdzanie poprawności składni i zgodności dokumentów.

3. Współpraca Wykorzystanie narzędzi takich jak Git umożliwia wspólną pracę nad dokumentacją:

   • Każdy członek zespołu może zgłaszać propozycje zmian za pomocą pull requestów.
   • Historia zmian jest przejrzysta i łatwa do śledzenia.
   • Możesz używać tych samych narzędzi i procesów co w przypadku kodu (np. code review).

4. Spójność Dokumentacja zawsze odzwierciedla aktualny stan projektu, co minimalizuje ryzyko błędów i niespójności. Jeśli coś się zmienia w kodzie, zmiana ta może automatycznie wpłynąć na generowaną dokumentację.

Jak wdrożyć Documentation as Code?

1. Wybierz narzędzia

• PlantUML: Do generowania diagramów UML (sekwencji, klas, komponentów itp.) bezpośrednio z plików tekstowych.
• Structurizr: Do modelowania architektury w stylu C4, z możliwością integracji z kodem.
• arc42: Do dokumentowania architektury systemu w uporządkowany i spójny sposób.
• Asciidoctor lub Markdown: Do tworzenia dokumentacji tekstowej w lekkim formacie, który łatwo można przetworzyć na HTML lub PDF.

2. Zintegruj dokumentację z pipeline CI/CD

• Skonfiguruj kroki w CI/CD, które generują i publikują dokumentację.
• Użyj narzędzi takich jak GitHub Actions, GitLab CI, czy Jenkins do automatyzacji procesu.

3. Twórz dokumentację jako kod

• Zamiast pisać statyczne dokumenty, zapisuj dane w formacie tekstowym (np. DSL, Markdown).
• Korzystaj z automatycznych generatorów, które przekształcą te dane w finalne dokumenty.

4. Uczyń dokumentację częścią workflow

• Dokumentację aktualizuj razem z kodem – każda zmiana funkcjonalności powinna być odzwierciedlona w dokumentacji.
• Wymagaj aktualizacji dokumentacji jako elementu procesu przeglądu kodu (code review).

Przykład praktyczny – Integracja z CI/CD

Załóżmy, że tworzysz dokumentację architektury systemu przy użyciu Structurizr DSL i Asciidoctor. Możesz skonfigurować pipeline CI/CD w następujący sposób:

1. Etap 1: Generowanie diagramów
   Uruchom skrypt generujący diagramy na podstawie plików DSL.

   
   structurizr-cli export -workspace workspace.dsl -format plantuml
   

2. Etap 2: Tworzenie dokumentacji
   Użyj Asciidoctor, aby wygenerować dokument HTML lub PDF.

   
   asciidoctor -b html5 dokumentacja.adoc
   

3. Etap 3: Publikacja
   Opublikuj wygenerowaną dokumentację w serwisie takim jak GitHub Pages lub serwerze wewnętrznym.

Podsumowanie

Podejście Documentation as Code zmienia sposób, w jaki patrzymy na dokumentację – z nudnego obowiązku na integralną część procesu tworzenia oprogramowania. Dzięki automatyzacji, integracji z pipeline CI/CD i wspólnej pracy nad dokumentami, dokumentacja staje się dynamiczna, aktualna i spójna z projektem.

Zapraszam do kontaktu i rezerwacji terminów na warsztaty oraz konsultacje. Razem usprawnimy Twoje procesy dokumentacyjne i architektoniczne!

Więcej na stronie: 

https://softwareveteran.dev/#offer

EA - Czym jest Software Bill of Materials?

 SBOM (Software Bill of Materials), czyli "spis treści" oprogramowania, to dokument, który zawiera szczegółowy wykaz wszystkich komponentów używanych w danej aplikacji, w tym bibliotek open-source, frameworków i innych zależności. W kontekście narzędzia OWASP Dependency-Track, SBOM pełni kluczową rolę w zarządzaniu bezpieczeństwem i zgodnością oprogramowania.

Dlaczego SBOM jest ważne?

1. Przejrzystość: Dzięki SBOM zespół ma pełny obraz używanych zależności, co ułatwia identyfikację potencjalnych podatności.
2. Zgodność regulacyjna: SBOM staje się coraz bardziej wymagane przez przepisy prawa, takie jak Executive Order on Improving the Nation’s Cybersecurity w USA, które nakładają obowiązek dostarczania SBOM przez dostawców oprogramowania.
3. Monitorowanie ryzyk: SBOM pozwala szybko reagować na nowe podatności, ponieważ dokładnie wiadomo, które komponenty wymagają uwagi.

Dependency-Track i SBOM

Dependency-Track automatycznie generuje i zarządza SBOM dla każdego projektu. Narzędzie obsługuje formaty standardowe, takie jak:

• CycloneDX – rekomendowany format SBOM rozwijany przez OWASP.
• SPDX (Software Package Data Exchange) – szeroko stosowany w dużych projektach open-source.

Dzięki wbudowanej obsłudze SBOM, Dependency-Track:

• Analizuje wszystkie komponenty wymienione w SBOM pod kątem znanych podatności.
• Monitoruje zmiany w zależnościach na przestrzeni czasu.
• Pozwala na łatwe udostępnianie SBOM interesariuszom i partnerom w celu spełnienia wymagań zgodności.

Praktyczne zastosowanie SBOM

Przykład: Jeśli pojawi się nowa podatność w popularnej bibliotece open-source, Dependency-Track automatycznie porówna SBOM projektu z bazą danych podatności (np. CVE). Jeśli podatna wersja znajduje się w projekcie, zespół natychmiast otrzyma ostrzeżenie wraz z zaleceniem aktualizacji lub usunięcia podatnego komponentu.

Budowanie SBOM (Software Bill of Materials) jest kluczowe dla zarządzania bezpieczeństwem zależności w projektach programistycznych. W różnych językach programowania można wykorzystać różne narzędzia i techniki do automatycznego generowania SBOM. Poniżej przedstawiam najpopularniejsze rozwiązania dla języków Java, C#, PHP i JavaScript.

1. Java

Java wykorzystuje narzędzia zarządzania zależnościami, takie jak Maven czy Gradle, które są kompatybilne z formatami SBOM, takimi jak CycloneDX.

Budowanie SBOM w Maven:

1. Zainstaluj wtyczkę CycloneDX:

   <plugin>
       <groupId>org.cyclonedx</groupId>
       <artifactId>cyclonedx-maven-plugin</artifactId>
       <version>2.7.9</version>
   </plugin>
   

2. Uruchom wtyczkę:

   mvn cyclonedx:makeAggregateBom
   

3. Plik SBOM (bom.xml) zostanie wygenerowany w katalogu projektu.

Budowanie SBOM w Gradle:

1. Dodaj wtyczkę CycloneDX do build.gradle:

   plugins {
       id "org.cyclonedx.bom" version "1.7.4"
   }
   

2. Wygeneruj SBOM:

   gradle cyclonedxBom
   

3. Plik SBOM (bom.xml lub bom.json) znajdziesz w katalogu build/reports.

---

2. C#

W ekosystemie .NET generowanie SBOM można zrealizować za pomocą narzędzia dotnet CLI lub specjalnych bibliotek.

Budowanie SBOM za pomocą dotnet CLI:

1. Zainstaluj narzędzie dotnet-project-assets:

   dotnet tool install -g dotnet-project-assets
   

2. Wygeneruj SBOM:

   dotnet-project-assets
   

3. Plik sbom.json zawierający zależności projektu zostanie utworzony.

Inne narzędzia:

• Użycie platformy CycloneDX: istnieją gotowe wtyczki dla .NET pozwalające na generowanie SBOM w formacie CycloneDX.

---

3. PHP

W projektach PHP zależności są zarządzane przez Composer, który również wspiera generowanie SBOM.

Budowanie SBOM za pomocą Composer:

1. Dodaj wtyczkę Composer CycloneDX:

   composer require --dev cyclonedx/cyclonedx-php-composer
   

2. Wygeneruj SBOM:

   vendor/bin/cyclonedx-composer make-bom
   

3. Plik SBOM (bom.json) zostanie zapisany w katalogu projektu.

Dodatkowe rozwiązania:

• Narzędzia takie jak SCA (Software Composition Analysis) mogą również generować SBOM dla projektów PHP.

---

4. JavaScript (Node.js)

W projektach JavaScript i Node.js używa się narzędzi takich jak npm lub yarn do zarządzania zależnościami.

Budowanie SBOM za pomocą CycloneDX npm:

1. Zainstaluj CycloneDX CLI:

   npm install -g @cyclonedx/cyclonedx-npm
   

2. Wygeneruj SBOM:

   
   cyclonedx-npm --output bom.json
   

3. Plik bom.json zostanie zapisany w katalogu projektu.

Budowanie SBOM za pomocą yarn:

1. Zainstaluj wtyczkę CycloneDX:

   yarn global add @cyclonedx/cyclonedx-npm
   

2. Wygeneruj SBOM:

   cyclonedx-npm --output bom.json
   

Podsumowanie roli SBOM w Dependency-Track

SBOM jest fundamentem skutecznego zarządzania zależnościami. W kontekście Dependency-Track to nie tylko dokument, ale także narzędzie, które zapewnia bezpieczeństwo, przejrzystość i zgodność oprogramowania. Dzięki automatycznemu generowaniu i monitorowaniu SBOM, zespoły DevOps mogą zyskać pełną kontrolę nad komponentami swoich aplikacji i szybko reagować na pojawiające się zagrożenia.

dev{ops}: OWASP Dependency-Track – Narzędzie do Zarządzania Bezpieczeństwem Zależności

 W artykułach o podejściu Shift Left („DevOps: Shift Left – Podejście do Bezpieczeństwa”) oraz metodach SAST i DAST („Dev{tools}: SAST i DAST – Bezpieczeństwo Aplikacji od Wczesnych Etapów do Testowania Produkcyjnego”) omówiłem kluczowe podejścia do zapewniania bezpieczeństwa oprogramowania. Teraz przyjrzyjmy się, jak OWASP Dependency-Track wypada w porównaniu z innymi popularnymi narzędziami, takimi jak SonarQube i OWASP ZAP, oraz jak wszystkie te narzędzia mogą uzupełniać się w strategii DevOps.

OWASP Dependency-Track w połączeniu z SonarQube i OWASP ZAP

1. Dependency-Track: Zewnętrzne zależności

Dependency-Track skupia się na identyfikacji i monitorowaniu podatności w bibliotekach, frameworkach i innych komponentach zewnętrznych. Dzięki temu narzędzie pozwala na:

• Proaktywne zarządzanie ryzykiem w używanych zależnościach.
• Stałe monitorowanie zagrożeń w czasie rzeczywistym.
• Automatyzację analizy w pipeline CI/CD.

Dependency-Track jest szczególnie użyteczne w dużych projektach korzystających z wielu zależności open-source, gdzie podatności mogą stanowić istotne zagrożenie.

2. SonarQube: Analiza kodu źródłowego

SonarQube to narzędzie do analizy statycznej kodu, które pozwala na wykrywanie problemów w implementacji, takich jak:

• Brak walidacji danych wejściowych.
• Użycie niebezpiecznych funkcji.
• Problemy z wydajnością lub jakością kodu.

SonarQube uzupełnia Dependency-Track, zapewniając bezpieczeństwo i jakość kodu napisanego wewnętrznie przez zespół deweloperski.

3. OWASP ZAP: Testy dynamiczne

OWASP ZAP (Zed Attack Proxy) to narzędzie do dynamicznego testowania bezpieczeństwa, które pozwala na:

• Symulację ataków na aplikację w czasie rzeczywistym.
• Testowanie API i aplikacji webowych pod kątem problemów runtime, takich jak brak autoryzacji czy Cross-Site Scripting (XSS).
• Wykrywanie problemów, które mogą pojawić się tylko podczas rzeczywistego działania aplikacji.

OWASP ZAP doskonale uzupełnia Dependency-Track i SonarQube, testując aplikację jako całość w środowisku runtime.

Przykład praktycznego zastosowania wszystkich narzędzi

1. Etap implementacji
   Na tym etapie wprowadzam SonarQube, aby sprawdzić, czy kod źródłowy spełnia standardy bezpieczeństwa i jakości. Dzięki integracji z CI/CD kod każdego dewelopera jest automatycznie analizowany przy commitcie.

2. Etap budowy i integracji
   Tutaj używam Dependency-Track, aby przeanalizować zależności w projekcie i upewnić się, że żadne zewnętrzne biblioteki nie zawierają znanych podatności. Jeśli takowe znajdę, mogę szybko zaktualizować komponenty lub usunąć te ryzykowne.

3. Etap testów
   Na etapie testowania aplikacji wdrażam OWASP ZAP, aby symulować rzeczywiste ataki na działającą aplikację. Dzięki temu sprawdzam, czy aplikacja jest odporna na zagrożenia w runtime, takie jak nieautoryzowany dostęp czy błędy konfiguracji.

4. Etap produkcji
   Po wdrożeniu aplikacji kontynuuję monitorowanie zależności za pomocą Dependency-Track oraz regularnie uruchamiam testy dynamiczne w OWASP ZAP, aby upewnić się, że nowe podatności nie pojawiły się w używanych komponentach.

Dlaczego warto używać wszystkich trzech narzędzi?

Każde z tych narzędzi koncentruje się na innym aspekcie bezpieczeństwa:

• Dependency-Track monitoruje bezpieczeństwo komponentów zewnętrznych, kluczowych w nowoczesnym oprogramowaniu.
• SonarQube zapewnia wysoką jakość kodu źródłowego i eliminuje podatności na etapie implementacji.
• OWASP ZAP testuje działającą aplikację, symulując rzeczywiste zagrożenia w środowisku runtime.

Łącząc te trzy narzędzia w strategii DevOps, mogę skutecznie zarządzać bezpieczeństwem w całym cyklu życia oprogramowania, minimalizując ryzyko i zwiększając zaufanie użytkowników do mojego produktu.

Podsumowanie

OWASP Dependency-Track, w połączeniu z SonarQube i OWASP ZAP, tworzy kompletny zestaw narzędzi, które wspierają strategię Shift Left i DevOps. Każde z tych narzędzi ma swoją specjalizację, ale razem zapewniają pełne pokrycie analizy bezpieczeństwa od kodu źródłowego, przez zależności, po runtime. Wykorzystanie tych narzędzi pozwala na budowanie bezpieczniejszych, bardziej niezawodnych aplikacji i lepsze zarządzanie ryzykiem w dynamicznym środowisku IT.

Nowy Rok, Nowe Możliwości: Warsztaty i Konsultacje w Zakresie PlantUML, C4, Structurizr i arc42

 

Z nowym rokiem otwieram nowy rozdział w swojej działalności! Od dziś oferuję profesjonalne warsztaty oraz prywatne konsultacje w zakresie nowoczesnych narzędzi i metodyk zarządzania architekturą oprogramowania:

• PlantUML - automatyzacja tworzenia diagramów i wizualizacji systemów,
• C4 Model - przejrzyste przedstawienie złożonych systemów w różnych poziomach szczegółowości,
• Structurizr - innowacyjne podejście do modelowania architektury,
• arc42 - szablon dokumentacji architektonicznej, który usprawnia komunikację i organizację w projektach.

Moje usługi obejmują zarówno kompleksowe szkolenia, jak i indywidualne wsparcie dostosowane do potrzeb Twojej organizacji. Jeśli chcesz unowocześnić dokumentację swojej architektury, zautomatyzować procesy lub lepiej komunikować się w zespole, skontaktuj się ze mną już dziś!

Zapraszam do kontaktu i rezerwacji terminów na warsztaty oraz konsultacje. Razem usprawnimy Twoje procesy dokumentacyjne i architektoniczne!

Więcej na stronie: 

https://softwareveteran.dev/#offer