Jaka jest dobra metoda oceny lekkiej architektury?

Znam metody oceny architektury, takie jak techniczna metoda analizy kompromisu architektury (ATAM) i bardziej zorientowana na biznes metoda analizy korzyści i kosztów (CBAM) . Jednak metody te mają dość dużą skalę: zalecają kilka sesji burzy mózgów, prezentacji, opracowania wielu scenariuszy opisujących kompromisy itp. Mimo że są przydatne w projektach o określonej wielkości, są zbyt duże dla projektów wewnętrznych lub aplikacji komputerowych, które są zwykle opracowane przez garstkę programistów (lub mniej), które mimo że są małe, mają pewne dość wysokie ograniczenia jakości (wydajność, skalowalność, adaptowalność).

Typową praktyką, z której korzystałem w przeszłości, jest posiadanie jednego programisty (lub architekta, jeśli zespół taki ma), który opracowuje ogólną architekturę aplikacji, a następnie omawia ją na tablicy z resztą zespołu, zwykle używając niektóre notacje pseudo-UML, które są łatwe do narysowania i zrozumienia. Zwykle prowadzi to do informacji zwrotnych i niektórych iteracji dotyczących architektury. Ale wydaje się, że jest to zbyt nieformalne podejście, które powoduje, że przyjmowane są wszelkiego rodzaju założenia, które później mogą okazać się błędnymi decyzjami.

Metody takie jak ATAM zazwyczaj zmuszają wszystkich interesariuszy do głębokiego myślenia o architekturze, co prowadzi do dyskusji, dopóki wszyscy przynajmniej nie uzgodnią, czym dokładnie jest architektura .

Czy ktoś ma doświadczenie w przeprowadzaniu lekkiej oceny architektury z góry? Jeśli tak, jakie są dobre praktyki?

Kluczem do lekkiej oceny jest ocena właściwych rzeczy we właściwym czasie. Istnieją dwa sposoby, aby to zrobić skutecznie. W przypadku oceny opartej na scenariuszu używasz scenariuszy atrybutów jakości i przypadków użycia, aby kierować oceną, koncentrując się tylko na atrybutach jakości o wysokim priorytecie. Dzięki ocenie opartej na ryzyku identyfikujesz ryzyka i pozwalasz zidentyfikowanym ryzykom kierować działaniami projektowymi architektury.

Są dwie książki, które mogę polecić, które badają te dwa (nieco powiązane) podejścia.

Intensywne oprogramowanie architektoniczne Anthony Lattanze wprowadza metodologię projektowania zorientowanego na architekturę i obejmuje lekkie oceny oparte na scenariuszach. Możesz rozpoznać Lattanze z warsztatu jakości atrybutów SEI i są w to podobne pomysły.

Wystarczająca architektura oprogramowania: podejście oparte na ryzyku autorstwa George'a Fairbanks wprowadza, no cóż, podejście oparte na ryzyku do projektowania i oceny architektury systemu oprogramowania. Na jego stronie internetowej dostępne są również bezpłatne rozdziały, jeśli chcesz uzyskać podgląd. Chociaż zasady zawarte w tej książce mają natychmiastowe zastosowanie, podejście nie zawiera konkretnej metody, więc będziesz musiał połączyć pomysły z innych dziedzin. Gorąco polecam podejście SEI do ciągłego zarządzania ryzykiem w celu identyfikacji / ustalania priorytetów ryzyka.

Podstawową ideą tych podejść jest obniżenie kosztów oceny (i projektowania) poprzez ewaluację w trakcie pracy, a nie czekanie do końca. Chociaż jest to z pewnością nieco cięższy sposób niż rozmawianie na tablicy, nie jest to tak kosztowne jak w pełni rozwinięty ATAM. A jeśli czujesz się komfortowo, możesz wybrać praktyki, które spełnią Twoje specyficzne potrzeby.

Bez względu na to, jakiego podejścia użyjesz do przeprowadzenia oceny, ogólny pomysł będzie taki sam ...

Zanim zaczniesz:

• Scenariusze atrybutów jakości lub ryzyka, uszeregowane według priorytetów (może być nieformalne, jeśli to wszystko, co masz)
• Jasna definicja decyzji „go / no-go” (skąd wiesz, że architektura jest „wystarczająco dobra”)
• Najnowsze wycięcie opisu architektury (artefakt, który oceniasz)

Usiądź na sesji ewaluacyjnej:

• Architekt przedstawia przegląd architektury
• Przejdź przez widok, pokaż, w jaki sposób scenariusz lub ryzyko jest spełnione
• Problemy są rejestrowane do rozwiązania w późniejszym terminie
• Role i ogólna procedura są podobne do tych stosowanych podczas inspekcji Fagana (architekt lub autor, moderator, rejestrator).
• Sesja może potrwać nawet godzinę lub dwie, w zależności od wielkości twojego systemu.

Po zakończeniu sesji:

• Przejrzyj zidentyfikowane problemy i ustal, czy spełnione są kryteria wejścia / wyjścia. Zasadniczo wszystko zajmuje około 3 recenzji. Jeśli nie zostanie spełniony, kontynuuj udoskonalanie i eksperymentowanie (lub ograniczanie ryzyka związanego z architekturą).
• To nie jest ocena „wszystko albo nic” - różne części twojej architektury mogą „przejść”, podczas gdy inne nadal wymagają dopracowania.

Aby pomóc Ci poczuć, jak może wyglądać podejście oparte na scenariuszu, istnieje pewna publiczna dokumentacja z projektu zwieńczenia , nad którym pracowałem w szkole. Dokumentacja jest nieco przybliżona, ale może pomóc podać kilka przykładów podejścia opartego na scenariuszach w kontekście ACDM. Byliśmy zespołem 5 osób i zbudowaliśmy typową aplikację internetową, około 35 KLOC Java / GWT.

Na początek lubię nieformalne dyskusje na tablicy. Lubię pisać tylko część aplikacji, która jest dziś potrzebna, a następnie stopniowo pozwalać na pojawienie się architektury podczas implementacji. Bardziej przypomina „znalezienie architektury” niż próbę jej wcześniejszego wynalezienia. Takie podejście nie wymaga dużej wstępnej oceny i pomaga skupić się na tym, co ważne (dostarczyć działające oprogramowanie).

Oczywiście, jeśli wymagają tego niefunkcjonalne wymagania (ograniczenia pamięci, czasy odpowiedzi, liczba równoczesnych użytkowników itp.), Należy wziąć to pod uwagę przy wdrażaniu systemu.