Przewodnik po zintegrowanej platformie Visual Paradigm

Rysunek przedstawia zintegrowaną platformę Visual Paradigm jako zintegrowane środowisko do zarządzania pełnym cyklem życia oprogramowania i analizy biznesowej – od początkowych potrzeb biznesowych, przez wymagania, modelowanie, projektowanie, implementację, aż po dokumentację.

Zamiast używać rozłącznych narzędzi do każdej czynności, platforma łączy informacje o projekcie w wspólnym środowisku pracy. Ułatwia to analitykom, projektantom, programistom, architektom, menedżerom projektów i interesariuszom pracę na podstawie tego samego źródła informacji.

1. Zrozumienie koncepcji zintegrowanej platformy

Zintegrowana platforma łączy powiązane artefakty projektu w jednym spójnym środowisku. Artefakty te mogą obejmować:

• Cele i potrzeby biznesowe

• Wymagania

• Scenariusze użycia i historie użytkownika

• Modele UML i inne modele wizualne

• Diagramy procesów

• Projekty baz danych

• Projekty interfejsu użytkownika

• Mapowania kodu źródłowego

• Dokumentacja projektu

• Raporty i specyfikacje

Kluczowa idea nie polega jedynie na tym, że wszystkie te narzędzia są dostępne w jednej aplikacji. Większą korzyścią jest to, że artefakty mogą być powiązane ze sobą.

Na przykład:

Cel biznesowy może być powiązany z wymaganiami, wymagania ze scenariuszem użycia, scenariusz użycia z modelem projektowym, a model projektowy z dokumentacją implementacji.

Tworzy to bardziej spójną strukturę projektu i zmniejsza ryzyko utraty informacji w miarę postępu prac nad projektem.

2. Przestrzeganie pełnego cyklu życia projektu

Rysunek przedstawia cykl życia składający się z sześciu powiązanych etapów:

1. Potrzeba biznesowa

2. Wymagania

3. Modele

4. Projektowanie

5. Wdrożenie

6. Dokumentacja

Te etapy nie powinny być traktowane jako izolowane fazy. Informacje powinny przepływać między nimi w sposób ciągły.

Etap 1: Potrzeba biznesowa

Zacznij od udokumentowania problemu biznesowego, szansy lub celu.

Przykłady obejmują:

• Skrócenie czasu przetwarzania ręcznego

• Poprawa samoobsługi klientów

• Zastąpienie przestarzałego systemu

• Wsparcie nowego procesu biznesowego

• Spełnienie wymogów regulacyjnych lub operacyjnych

Na tym etapie skup się na pożądanym wyniku biznesowym, a nie na wdrożeniu technicznym.

Przydatne wyniki mogą obejmować:

• Cele biznesowe

• Stwierdzenia problemów

• Opisy interesariuszy

• Zadania biznesowe

• Mapy kompetencji

• Diagramy procesów wysokiego poziomu

• Definicje zakresu

Jasna potrzeba biznesowa pomaga zapewnić, że późniejsze wymagania i decyzje techniczne pozostają zgodne z powodem istnienia projektu.

Etap 2: Wymagania

Przetłumacz potrzeby biznesowe na konkretne, testowalne wymagania.

Wymagania mogą opisywać:

• Co użytkownicy muszą zrobić

• Co system musi zrobić

• Zasady biznesowe

• Wymagania dotyczące danych

• Oczekiwania dotyczące wydajności

• Ograniczenia bezpieczeństwa

• Obowiązki regulacyjne

• Potrzeby integracyjne

Wspólne artefakty wymagań obejmują:

• Historie użytkowników

• Scenariusze użycia

• Wymagania funkcjonalne

• Wymagania niefunkcjonalne

• Kryteria akceptacji

• Hierarchie wymagań

• Łącza śledzenia

Każde wymaganie powinno idealnie mieć jasny związek z jednym lub więcej celami biznesowymi. Ułatwia to określenie, czy projekt dostarcza wartości biznesowej o znaczeniu.

Etap 3: Modele

Modele zapewniają wizualne przedstawienie systemu, organizacji, danych lub procesów.

W zależności od projektu modele mogą obejmować:

• Diagramy scenariuszy użycia

• Diagramy aktywności

• Diagramy klas

• Diagramy sekwencji

• Diagramy maszyn stanów

• Modele procesów biznesowych

• Diagramy relacji encji

• Diagramy architektury

• Diagramy przepływu danych

• Mapy podróży klienta

Modele pomagają zespołom łatwiej zrozumieć złożoność niż sam tekst. Zapewniają również wspólny język dla interesariuszy technicznych i nietechnicznych.

Na przykład:

• Interesariusz biznesowy może zrozumieć model procesu.

• Programista może pracować na podstawie diagramu klas lub sekwencji.

• Projektant bazy danych może użyć modelu relacji encji.

• Architekt może użyć diagramu wdrożenia lub diagramu komponentów.

Zjednoczona platforma umożliwia utrzymanie tych różnych widoków jako części tego samego projektu.

Etap 4: Projektowanie

Projektowanie przekształca wymagania i modele w bardziej szczegółową strukturę rozwiązania.

Działania projektowe mogą obejmować:

• Architektura systemu

• Komponenty aplikacji

• Schematy baz danych

• Interfejsy użytkownika

• API i integracje

• Środowiska wdrożenia

• Architektura bezpieczeństwa

• Granice usług

• Szczegółowe przepływy pracy

Solidny projekt powinien być możliwy do просledzenia do wymagań, które spełnia. Jeśli element projektu nie może być powiązany z wymaganiami, zespół powinien ustalić, czy jest on niezbędny, czy brakuje go w wymaganiach, czy też wykracza poza zakres.

Etap 5: Implementacja

Implementacja to etap, w którym projekt jest przekształcany w działające oprogramowanie, skonfigurowane procesy, struktury baz danych lub inne dostarczone elementy.

Platforma może pomóc w połączeniu projektowania i implementacji poprzez relacje między:

• Modele i kod źródłowy

• Projekty baz danych i skrypty baz danych

• Wymagania i zadania deweloperskie

• Komponenty i usługi

• API i szczegóły implementacji

• Diagramy i dokumentacja techniczna

To połączenie pomaga zmniejszyć lukę między tym, co zostało zaprojektowane, a tym, co faktycznie zbudowano.

Etap 6: Dokumentacja

Dokumentacja utrwalą ważną wiedzę projektu w formie, która może być udostępniana, przeglądana, utrzymywana i ponownie wykorzystywana.

Możliwe dokumenty obejmują:

• Specyfikacje wymagań

• Opisy projektowania oprogramowania

• Dokumentacja architektury

• Podręczniki użytkownika

• Dokumentacja API

• Specyfikacje testów

• Raporty projektowe

• Rejestr zgodności

• Procedury operacyjne

Gdy dokumentacja jest generowana lub składana z powiązanych artefaktów projektu, mniej prawdopodobne jest, że stanie się niespójna z podstawowymi modelami i wymaganiami.

3. Korzyść pierwsza: Użyj połączonego środowiska pracy projektu

Pierwsza korzyść na rysunku to jedno połączone środowisko pracy projektu.

Połączone środowisko pracy umożliwia zarządzanie informacjami projektowymi w jednym środowisku, zamiast rozprzestrzeniania ich między niezwiązanymi narzędziami, plikami i repozytoriami.

Dlaczego to ma znaczenie

Niezwiązane narzędzia często powodują problemy, takie jak:

• Wiele wersji tego samego wymagania

• Diagramy, które nie odpowiadają już implementacji

• Zduplikowane wprowadzanie danych

• Brakujące połączenia między artefaktami biznesowymi a technicznymi

• Trudności w odnalezieniu najnowszych informacji projektowych

• Sprzeczna terminologia

• Ręczna praca przy przygotowywaniu raportów

Połączone środowisko pracy ułatwia lokalizację i utrzymanie informacji projektowych.

Zalecana praktyka

Utwórz spójną strukturę projektu z obszarami dla:

• Analiza biznesowa

• Wymagania

• Modele

• Architektura i projektowanie

• Dane

• Odniesienia do implementacji

• Dokumentacja

• Przeglądy i zatwierdzenia

Używaj wspólnych konwencji nazewnictwa i łącz powiązane artefakty zamiast kopiować tę samą informację do wielu miejsc.

4. Korzyść druga: Szybszy dostęp do odpowiedniego narzędzia

Drugą korzyścią jest szybszy dostęp do odpowiedniego narzędzia dla każdego zadania.

Projekt może wymagać wielu różnych rodzajów pracy, w tym:

• Zarządzanie wymaganiami

• Modelowanie procesów

• Modelowanie UML

• Projektowanie baz danych

• Prototypowanie interfejsu użytkownika

• Modelowanie architektury

• Planowanie zwinne

• Generowanie dokumentacji

• Inżynieria kodu lub baz danych

Gdy te możliwości są dostępne w zintegrowanym środowisku, członkowie zespołu spędzają mniej czasu na przełączanie się między aplikacjami lub ponowne tworzenie informacji w innym formacie.

Skutek praktyczny

Analityk biznesowy może przejść od modelu procesu do powiązanych z nim wymagań. Architekt może przejść od wymagania do odpowiedniego projektu systemu. Programista może skonsultować model i powiązaną dokumentację techniczną bez przeszukiwania niepowiązanych folderów.

Celem jest udostępnienie następnego istotnego artefaktu w kontekście.

5. Korzyść Trzecia: Popraw Śledzenie

Śledzenie jest zdolnością zdolnością do śledzić cykl związki między projektu artefaktami przez cały cykl rozwoju życiowego. Pomaga zespołom zrozumieć jak potrzeby biznesowe są przekształcane w wymagania, projekty, implementacje i udokumentowane rezultaty. Typowy

łańcuch prześledzenia łańcuch może wyglądać jak to:

$\text{Biznes Potrzeba}\to \text{Wymaganie}\to \text{Użycie Przypadek}\to \text{Projekt Element}\to \text{Implementacja}\to \text{Dokumentacja}$

Śledzenie może także rozciągać się na testowanie:

$\text{Wymaganie}\to \text{Akceptacja Kryterium}\to \text{Test Przypadek}\to \text{Test Wynik}$

To połączona struktura pomaga zespołom:

• Zrozumieć źródło i cel każdej decyzji projektowania Zidentyfikować które
• elementy systemu są dotknięte gdy wymagania zmieniają Potwierdzić
• że każdy wymaganie został zrealizowany wdrożony
• Sprawdź że wymagania są objęte przez kryteria przyjęcia i testów przypadków
• Zmniejsz zduplikowane lub niezgodne informacje projektu
• Wspieraj audyty, przeglądy, konserwację, i analizę wpływu

Z platformą Visual Paradigm Zjednoczoną Platformą, zespoły mogą łączyć wymagania, modele, projekty, implementację artefakty, testy, przejrzystym dokumentację w bardziej strukturyzowanym i przejrzystym przebiegu pracy.

Dlaczego śledzenie jest ważne

Śledzenie pomaga odpowiadać na pytania takie jak:

• Jakie cel biznesowy wspiera ta funkcja?

• Które wymagania są objęte proponowaną zmianą?

• Czy każde wymaganie zostało zaprojektowane i zaimplementowane?

• Które komponenty zależą od tego wymagania?

• Którą dokumentację należy zaktualizować?

• Jakie dowody potwierdzają zgodność?

• Jakie testy potwierdzają, że wymaganie zostało spełnione?

Analiza wpływu zmian

Załóżmy, że wymaganie ulega zmianie. Dzięki powiązanym relacjom zespół może zidentyfikować potencjalnie zagrożone:

• Scenariusze użycia

• Schematy procesów

• Modele danych

• Projekty interfejsów

• Komponenty architektury

• Zadania wdrożeniowe

• Scenariusze testowe

• Dokumentacja

Jest to znacznie bezpieczniejsze niż poleganie na pamięci lub ręcznym przeszukiwaniu plików projektu.

6. Korzyść czwarta: Poprawa komunikacji

Czwartą korzyścią jest poprawa komunikacji między uczestnikami projektu.

Różni interesariusze preferują różne sposoby rozumienia informacji. Zjednoczona platforma obsługuje wiele reprezentacji tego samego projektu, w tym:

• Wymagania w języku potocznym

• Schematy wizualne

• Tabele i macierze

• Prototypy

• Widoki architektury

• Przepływy procesów

• Wygenerowane raporty

Komunikacja z interesariuszami biznesowymi

Interesariusze biznesowi mogą nie potrzebować widoku kodu źródłowego lub szczegółowych modeli technicznych. Mogą czerpać większe korzyści z:

• Cele

• Schematy procesów

• Ścieżki użytkowników

• Scenariusze użycia

• Prototypy

• Zasady biznesowe

• Raporty podsumowujące

Komunikowanie się z zespołami technicznymi

Programiści, architekci i specjaliści od baz danych mogą potrzebować:

• Szczegółowe wymagania

• Diagramy klas

• Diagramy sekwencji

• Diagramy komponentów

• Modele danych

• Definicje API

• Widoki wdrożenia

• Mapowania implementacji

Ten sam połączony projekt może obsługiwać obie grupy odbiorców bez konieczności ręcznego odtwarzania informacji przez zespół.

Zalecane praktyki komunikacyjne

• Używaj diagramów do wyjaśniania złożonych relacji.

• Stosuj spójną terminologię na całym projekcie.

• Przejrzawiaj modele zarówno z udziałem uczestników technicznych, jak i biznesowych.

• Łącz decyzje z wymaganiami lub problemami, które rozwiązują.

• Twórz dokumentację dostosowaną do odbiorców tam, gdzie jest to stosowne.

• Utrzymuj diagramy aktualne w miarę zmian w projekcie.

7. Korzyść piąta: Wzmocnienie współpracy

Piątą korzyścią jest silniejsza współpraca między zespołami biznesowymi i technicznymi.

Projekty często kończą się niepowodzeniem, gdy oczekiwania biznesowe i wdrożenia techniczne rozwijają się oddzielnie. Zjednoczona platforma zachęca obie grupy do pracy z powiązanymi informacjami.

Współpraca między rolami

Typowy projekt może obejmować:

• Analitycy biznesowi

• Właściciele produktu

• Kierownicy projektów

• Eksperci dziedzinowi

• Projektanci UX

• Architekci rozwiązań

• Programiści

• Projektanci baz danych

• Inżynierowie testów

• Autorzy dokumentacji technicznej

• Zespoły operacyjne

Każda rola wnosi inną perspektywę. Połączenie ich pracy pomaga zespołowi wypracować wspólne zrozumienie rozwiązania.

Cykl wspólnego przeglądu

Praktyczny cykl współpracy wygląda następująco:

1. Zdefiniuj cel biznesowy.

2. Zdefiniuj i przeanalizuj wymagania.

3. Zamodeluj odpowiednie procesy i zachowania.

4. Zaprojektuj proponowane rozwiązanie.

5. Przejrzyj projekt ze stronami zainteresowanymi.

6. Wdroż zatwierdzone rozwiązanie.

7. Zaktualizuj modele i dokumentację.

8. Zweryfikuj, że dostarczony wynik spełnia pierwotne potrzeby.

Ten cykl zmniejsza ryzyko, że ważne decyzje pozostaną izolowane w spotkaniach, e-mailach lub pojedynczych dokumentach.

8. Korzyść szósta: Most między projektowaniem a wdrożeniem

Szósta korzyść polega na zniwelowaniu luki między projektowaniem a wdrożeniem.

Powszechnym problemem w projektach oprogramowania jest to, że dokumentacja projektowa jest tworzona na wczesnym etapie, ale nie jest aktualizowana w miarę zmian w systemie. Z czasem dokumentacja staje się oderwana od rzeczywistego wdrożenia.

Most między projektowaniem a wdrożeniem pomaga zespołom wykorzystywać modele jako praktyczne zasoby inżynieryjne, a nie wyłącznie dekoracyjne diagramy.

Przykłady połączeń między projektowaniem a wdrożeniem

• Model danych może wspierać generowanie bazy danych.

• Model klas może kierować wdrożeniem obiektowym.

• Model usług może wyjaśniać granice interfejsu API.

• Diagram komponentów może opisywać strukturę aplikacji.

• Model procesu może kierować konfiguracją przepływu pracy.

• Model interfejsu użytkownika może wspierać rozwój ekranów.

• Model wdrożenia może opisywać środowisko docelowe.

Dyscyplina wdrażania

Aby zachować zgodność:

• Łącz elementy wdrożenia z modelami, które realizują.

• Zapisuj decyzje projektowe i założenia.

• Aktualizuj modele, gdy zachodzą istotne zmiany we wdrożeniu.

• Przejrzyj, czy wygenerowane lub wyprowadzone artefakty pozostają dokładne.

• Unikaj traktowania diagramów jako jednorazowych dostaw.

• Wykorzystuj przeglądy modeli jako część zarządzania rozwojem.

Celem nie jest wymuszanie przedstawienia każdej linii kodu na diagramie. Celem jest utrzymanie odpowiedniego poziomu abstrakcji do komunikacji, projektowania, analizy i utrzymania.

9. Korzyść siódma: Tworzenie bardziej spójnej dokumentacji

Siódma korzyść to bardziej spójna dokumentacja.

Dokumentacja staje się niespójna, gdy wiele zespołów ręcznie utrzymuje nakładające się opisy tego samego systemu. Na przykład wymaganie może być zapisane w specyfikacji w jeden sposób, opisane inaczej na diagramie, a zaimplementowane pod inną nazwą w oprogramowaniu.

Zjednoczona platforma może pomóc zmniejszyć tę duplikację, wykorzystując powiązane artefakty jako podstawę raportów i dostaw.

Korzyści ze spójnej dokumentacji

• Mniej sprzecznych informacji

• Mniej powtarzającego się wprowadzania danych

• Szybsze przygotowanie dokumentów

• Łatwiejsza recenzja i zatwierdzenie

• Lepsze wdrażanie nowych członków zespołu

• Lepsze wsparcie dla audytów i zgodności

• Bardziej niezawodna dokumentacja utrzymaniowa

Dokumentacja powinna mieć jasnego właściciela

Dla każdego ważnego artefaktu określ:

• Kto go tworzy

• Kto go przegląda

• Kto go zatwierdza

• Jak zarządzane są zmiany

• Jak często jest aktualizowane

• Które inne artefakty ono wpływa

Wygenerowana dokumentacja jest przydatna tylko wtedy, gdy jej podstawowe informacje są właściwie utrzymywane. Automatyzacja może poprawić spójność, ale nie zastępuje nadzoru i przeglądu.

10. Wprowadź śledzalną metodę pracy

Praktycznym sposobem wykorzystania platformy jest definiowanie relacji w miarę rozwoju projektu.

Dla każdego głównego celu biznesowego zidentyfikuj:

• Wymagania, które je wspierają

• Procesy i przypadki użycia, które są zaangażowane

• Modele opisujące zachowanie

• Elementy projektu, które je realizują

• Testy, które je weryfikują

• Dokumentacja, która je wyjaśnia

Prosta macierz śledzalności może być używana jako mechanizm kontroli:

Cel biznesowy	Wymaganie	Projekt lub model	Odniesienie do implementacji	Weryfikacja
Zmniejsz czas przetwarzania	Zautomatyzuj proces zatwierdzania	Modele aktywności i procesów	Usługa przepływu pracy	Testy wydajności i odbiorcze
Popraw dostępność dla klientów	Zapewnij portal samoobsługowy	Przypadki użycia i projekt interfejsu użytkownika	Aplikacja portalu	Testy użyteczności i funkcjonalne
Ochrona danych wrażliwych	Wymuszaj dostęp oparty na rolach	Modele bezpieczeństwa i wdrożenia	Usługa autoryzacji	Testy bezpieczeństwa

Dokładne artefakty będą się różnić w zależności od projektu, ale zasada pozostaje ta sama: każdy ważny dostarczony element powinien mieć jasny cel i związek z pracą wokół niego.

11. Sugerowany przepływ pracy projektu

Poniższy przepływ pracy stosuje idee przedstawione na rysunku w praktyce.

Krok 1: Określ kontekst biznesowy

Dokumentuj problem, okazję, cele, interesariuszy oraz granice projektu.

Krok 2: Zbierz wymagania

Zapisz wymagania funkcjonalne, atrybuty jakości, reguły biznesowe, ograniczenia i kryteria odbioru.

Krok 3: Stwórz odpowiednie modele

Wybierz modele, które wyjaśniają problem i rozwiązanie. Unikaj tworzenia diagramów, które nie wspierają rzeczywistej decyzji, wyjaśnienia ani działalności inżynieryjnej.

Krok 4: Połącz powiązane artefakty

Połącz cele biznesowe z wymaganiami, wymagania z modelami, modele z elementami projektu, a elementy projektu z referencjami do implementacji lub testów.

Krok 5: Przeprowadź przegląd we współpracy

Zaprosz interesariuszy biznesowych i technicznych do przeglądu tych samych informacji o projekcie z perspektyw odpowiednich do ich ról.

Krok 6: Rozwijaj rozwiązanie

Używaj zatwierdzonych wymagań i projektów do kierowania implementacją.

Krok 7: Monitoruj zmiany

Gdy wymagania, projekty lub szczegóły implementacji ulegną zmianie, oceń skutki w dalszym ciągu i zaktualizuj dotknięte artefakty.

Krok 8: Generuj i utrzymuj dokumentację

Twórz specyfikacje, raporty, diagramy i dokumenty techniczne na podstawie bieżącej informacji o projekcie, gdzie jest to możliwe.

Krok 9: Zweryfikuj kompletność

Przed wydaniem potwierdź, że:

• Cele biznesowe zostały uwzględnione.

• Wymagania zostały spełnione.

• Ważne wymagania są śledzone.

• Projekt i implementacja są zgodne.

• Testy obejmują zamierzone zachowanie.

• Dokumentacja odzwierciedla dostarczony system.

12. Praktyki zarządzania, które czynią platformę skuteczną

A zjednoczona platformazapewnia środowisko, ale zespoły nadal potrzebują jasnych zasad pracy.

Stosuj konwencje nazewnictwa

Zdefiniuj spójne nazwy dla:

• Wymagania

• Procesy

• Aktorzy

• Systemy

• Komponenty

• Entity danych

• Usługi

• Dokumenty

Zdefiniuj właścicielstwo artefaktów

Przypisz odpowiedzialność za utrzymanie każdego głównego typu informacji.

Kontroluj wersje i zmiany

Rejestruj istotne zmiany i oceniaj ich wpływ na powiązane artefakty.

Unikaj niepotrzebnych duplikacji

Preferuj łączenie z udostępnionym artefaktem zamiast kopiowania tej samej informacji do wielu dokumentów.

Używaj odpowiedniego poziomu szczegółowości modelowania

Twórz modele wystarczająco szczegółowe, aby wspierać komunikację i inżynierię, ale nie tak szczegółowe, aby stały się trudne w utrzymaniu.

Przeprowadzaj regularne przeglądy

Planuj przeglądy w istotnych momentach kluczowych, takich jak:

• Zatwierdzenie wymagań

• Zatwierdzenie architektury

• Zakończenie projektu

• Walidacja przed wydaniem

• Ważne wnioski o zmianę

Mierz jakość projektu

Przydatne miary mogą obejmować:

• Procent wymagań z linkami śledzenia

• Liczba niepowiązanych elementów projektu

• Liczba nierozwiązanych uwag z przeglądu

• Czas aktualizacji dokumentacji

• Czas oceny wpływu zmian

• Pokrycie wymagań testami

• Liczba duplikatów lub sprzecznych artefaktów

13. Typowe błędy, których należy unikać

A zjednoczona platforma nie generuje automatycznie zjednoczonego procesu. Unikaj tych typowych problemów:

• Traktowanie platformy wyłącznie jako narzędzia do tworzenia diagramów

• Tworzenie modeli bez powiązania ich z wymaganiami

• Utrzymywanie wielu nieoficjalnych wersji tego samego artefaktu

• Nieaktualizowanie projektów po zmianach w implementacji

• Generowanie dokumentacji na podstawie przestarzałych informacji

• Angażowanie interesariuszy biznesowych wyłącznie na początku

• Nadmierna szczegółowość modeli w przypadku elementów o niskiej wartości

• Zakładanie istnienia śledzalności bez weryfikacji powiązań

• Używanie niespójnej terminologii między zespołami

• Traktowanie dokumentacji wyłącznie jako czynności na ostatnim etapie

14. Ogólna wartość

Główna myśl przedstawiona na rysunku polega na tym, że praca projektowa staje się bardziej efektywna, gdy biznes, wymagania, modelowanie, projektowanie, implementacja i dokumentacja są ze sobą powiązane.

Zjednoczone podejście może pomóc organizacjom:

• Utrzymać bardziej jasny obraz celów projektu

• Zmniejszyć izolację informacji

• Poprawić komunikację

• Wzmocnić współpracę

• Wcześniej identyfikować wpływ zmian

• Powiązać decyzje projektowe z implementacją

• Tworzyć bardziej wiarygodną dokumentację

• Zachowaj wiedzę przez cały cykl życia projektu

Krótko mówiąc, platforma wspiera ciągły łańcuch od dlaczego projekt jest potrzebnydo co musi zostać zbudowane, jak powinno być zaprojektowane, jak jest wdrażane, oraz jak wynik jest wyjaśniany i utrzymywany.