17
sty 13

Audyt architektury: analiza dokumentacji

W tym wpisie i w następnych oddalam się nieco od żywego oprogramowania, idąc w kierunku często zaniedbywanych, choć naprawdę niezbędnych, składników projektu. Na początek trywialna sprawa: dokumentacja…

Analiza dokumentacji

Motywacja/Cel
Analiza dokumentacji ma na celu głównie sprawdzenie jej kompletności i aktualności. Są to bardzo ważne aspekty, ponieważ dokumentacja jest podstawą dalszego rozwoju oprogramowania oraz leży u podstaw kształtowania procesów w projekcie.

Metoda
Analiza dokumentacji nie jest niczym innym jak “ręcznym” sprawdzeniem wszelkich dokumentów, które mają wpływ na kształtowanie oprogramowania i całego projektu. W szczególności należy poświęcić uwagę następującym zagadnieniom:

  • Czy dokumentacja jest aktualna? Czy jest w razie potrzeby na bieżąco aktualizowana?
  • Czy dokumentacja jest kompletna? Przez kompletność rozumiem tutaj to, że wszystkie fazy tworzenia aplikacji, wszystkie elementy natury biznesowej jak i elementy właściwego oprogramowania są opisane w sposób wystarczający i pozbawiony luk. W szczególności ważne jest zdefiniowanie zależności między warstwami aplikacji i innymi obiektami oraz sprecyzowanie używanych pojęć (glosariusz!)
  • Czy dokumentacja jest łatwo dostępna dla wszystkich uczestników projektu? Powinna ona znadjować się w z góry zdefiniowanym miejscu (katalog na serwerze, wiki itp.), które z łatwością jest dostępne dla wszystkich zainteresowanych. W idealnej sytuacji sposób przechowywania dokmentacji powinien zapewniać mechanizm wersjonowania.
  • Czy forma dokumentacji jest jednorodna w projekcie? Szablony dokumentacji usprawniają jej tworzenie i “konsumpcję” w ramach projektu.
    • (Kontr)przykład
      W jednym z projektów dokumentacja różnych modułów miała zupełnie różną formę, zakres i inną definicję tych samych pojęć. Doprowadziło to do kompletnego chaosu w implementacji i chociaż techniczna struktura aplikacji była we wszystkich modułach taka sama, to funkcjonalność rozkładała się zupełnie inaczej na różne warstwy. Dochodzący do tego brak wspónego rozumienia tak samo brzmiących nazw i terminów (brak glosariusza dla całego projektu) doskonale utrudniał komunikację pomiędzy architektami i programistami, prowadząc do zwiększonego nakładu pracy.


08
sty 13

Audyt architektury: Metryki

Metryki oprogramowania

Motywacja/Cel
Metryki oprogramowania to funkcje matematyczne, dzięki którym możliwa jest ilościowa (numeryczna) analiza kodu i ocena jego właściwości. Używamy ich w audycie, żeby ilościowo zobrazować lub uzasadnić jakościową ocenę oprogramowania.

Metoda
Istnieje niemal nieskończona ilość metryk oprogramowania ;) Ponieważ, mimo istnienia narzędzi automatycznie obliczających metryki, ich analiza i interpretacja jest uciążliwa i czasochłonna, należy wybrać te, których wartości dadzą najwięcej informacji potrzebnych do osiągnięcia celu audytu.
Poniżej prezentuję kilka metryk, stosowanych w ocenie łatwości konserwacji i dalszego rozwoju systemu informatycznego.

  • NCSS (Non Commenting Source Statements): jest to ilość linijek kodu w danej jednostce (jednym pliku, klasie, metodzie, funkcji), które nie są komentarzami. Zbyt wysoka wartość sugeruje, że badana jednostka kodu zawiera zbyt dużo funkcjonalności.
  • Ilość metod w klasie i klas w pakiecie: jest to odpowiednik NCSS na wyższym poziomie organizacji kodu. Zbyt wysokie wartości najczęściej oznaczają nieodpowiedni projekt danego modułu i zbyt dużą ilość funkcjonalności w jednostce kodu. Naturalnie w językach oprogramowania, które nie organizują kodu w klasy i pakiety, należy stosować metryki do odpowiednich struktur charakterystycznych dla tego języka.
  • CCN (Cyclomatic Complexity Number) opisuje, jak bardzo skomplikowany jest przepływ sterowania w programie. Jest to bardzo istotne dla testowania, eliminacji błędów oraz dalszego rozwoju oprogramowania. Im wyższy stopień skomplikowania, tym trudniej jest ocenić wpływ zmian w kodzie na jego funkcjonowanie.
  • Zduplikowany kod w zasadzie nie powienien istnieć. Zduplikowana implementacja logiki wymaga w przypadku wprowadzania zmian odnalezienie, modyfikacji i testowania kodu w wielu miejscach. Zasada DRY (Don’t Repeat Yourself) mówi, że powinno się unikać powtórzeń, aby zapewnić zachowanie konsystencji w aplikacji.
  • Cykliczne zależności między komponentami systemu (na różnych poziomach abstrakcji) wskazują na bardzo silne powiązania pomiędzy nimi. Oznacza to, że zmiany w jednym komponencie mogą mieć nieprzewidywalne efekty w zupełnie innych miejscach systemu (ripple effect), co najczęściej łączy się z podwyższonymi kosztami eliminacji błędów i testowania. Cykle często wynikają z nieodpowiedniego podziału funkcjonalności na warstwy lub moduły.

Przykład
Jako przykład poniżej prezentuję macierz zależności pomiędzy warstwami w badanym systemie. Plusy poniżej diagonali pokazują dopuszczalne zależności pomiędzy warstwami. W idealnym przypadku, powinny one jednak istnieć tylko na polach tuż pod diagonalą. Z macierzy widać też, że warstwy abs i sss leżą na jednym poziomie. Liczby powyżej diagonali pokazują ile razy zostały złamane zasady separacji warstw.


08
sty 13

Audyt architektury: Code-Walkthrough, Architecture-Walkthrough

Tym razem post z nie do końca polskim tytułem, ale nie widzę sensu tłumacznia akurat tych wyrażeń i właściwie nie znam też ich polskiego odpowiednika.

Code/Architecture-Walkthrough

Motywacja/Cel
Są to środki, które pozwalają na ocenę szczegółów implementacji danego systemu. Stosuje się je w celu zgromadzenia dodatkowych informacji dotyczących poprzednio zidentyfikowanych lub wcześniej znanych problemów.

Metoda
Code-Walkthrough polega na maualnej analizie dostępnego kodu źródłowego. Naturalnie w przypadku dużych projektów niemożliwe jest oglądnięcie całego kodu, dlatego należy sie skoncentrować na miejscach, gdzie potencjalnie mogą występować problemy. Te miejsca dostarcza nam analiza architektury.
Na poziomie technicznym należy sprawdzić na ile implementacja odpowiada aktualnym standardom programowania w danym języku. Natomiast na poziomie strukturalnym (architektura oprogramowania) skupiamy się na sprawdzeniu, czy implementacja pasuje do dokumentacji lub specyfikacji.

Warto przyglądnąć się nastepującym aspektom:

  • Struktura kodu (podział na pakiety, klasy, moduły, funkcje, w zależności od stosowanego języka programowania)
  • Czytelność kodu: ile wysiłku kosztuje odczytanie funkcjonalności z implementacji
  • Komentarze: czy kod jest wystarczająco skomentowany i (co nawet jest ważniejsze) czy komentarze są aktualne
  • Ogólnie przyjęte wzorce i antywzorce w programowniu

Jeśli w projekcie istnieją wytyczne dotyczące stylu programowania, warto zbadać kod również po kątem ich zachowania.


12
gru 12

Audyt architektury: ankiety

Dzisiaj przejdę już do konkretnych narzędzi, jakich możemy używać w czasie audytu architektury. Każde narzędzie chcę opisać podając motywację, względnie cel, jego stosowania oraz metodę.

Jako pierwsze prezentuję
Ankiety

Motywacja/Cel
Ankieta umożliwia jakościową ocenę wybranych obszarów architektury, jak również jej aktualnego stanu i mozliwości rozwoju w przyszłości. Dzięki tej ocenie możliwe będzie zidentyfikowanie ewentualnych “punktów zapalnych” i innych słabości, które należy szczegółowo zbadać w dalszych fazach audytu. Dodatkowo po zidentyfikowaniu obszarów, które znajdują się w najgorszym stanie, można ich użyć jako punktu wyjściowego do formułownia działań mających na celu poprawę sytuacji.

Metoda
Proponuję sformułowanie pytań do ankiety na bazie ogólnie przyjętych zasad i uznanych praktyk stosowanych w inżynierii oprogramowania. Dla każdego pytania należy sformułować “typową odpowiedź”, która posłuży potem jako pomoc przy ocenie ankiet wypełnionych przez uczestników projektu. Również każde pytanie powinno zostać ocenione w kontekście wpływu na cele projektu, to znaczy na ile dane zagadnienie jest ważne do jego osiągnięcia. Następnie należy pytania pogrupować w bloki tematyczne (w razie potrzeby wielopozomowo).

Pozostaje już tylko rozpowszechnienie ankiety pośród osób zaangażowanych w projekt i jej wypełnienie. Naturalnie najlepiej, jeśli uda się zebrać odpowiedzi od uczestników projektu, pełniących w nim różne role (programiści, architekci, kierownicy projektu itp.). Odpowiedzi możemy zbierać również w ramach przeprowadzanych wywiadów lub warsztatów.

Do analizy wyników ankiety polecam ich przedstawienie w formie wykresu zależności oceny konkretnych punktów od znaczenia dla projektu (obrazek). Wykres taki można sporządzić dla różnych poziomów abstrakcji, czy też różnych grup tematycznych. Zagadnienia leżące w obszarze charakteryzowanym przez wysokie znaczenie dla projektu i niską ocenę wymagają na pewno gruntownej analizy.


04
gru 12

Audyt architektury: zarys metody

Metoda przeprowadzania audytu architektury w zasadzie jest bardzo prosta, ogólna i składa się z kilku kroków:

  • Definicja celu audytu
  • Ustalenie obszarów objętych badaniem i konkretyzacja kryteriów
  • Przgotowanie narzędzi pracy (o tym w kolejnych artykułach)
  • Właściwe badanie architektury
  • Opracowanie zebranych danych (w tym ocena aktualnej architektury)
  • Sfomułowanie propozycji działań, ewentualnie konkretnych kroków, prowadzących do poprawy obecnej sytuacji

Bardzo ważne jest przy tym konkretne zdefiniowanie celu audytu, ponieważ to pociąga za sobą dobór obszarów badania i narzędzi. Owe obszary badania, jak napisałem, mogą się zmieniać od adytu do audytu. Poniżej krótkie zestawienie tych, które wydają mi się na tyle uniwersalne, że warto się nad nimi zastanowić w niemal każdym projekcie.

  • Procesy biznesowe: ich definicja i dokumentacja
  • Architektura biznesowa: modularyzacja, interfejsy i obiekty przenoszące dane (nie tylko encje bazodanowe!)
  • Architektura oprogramowania: techniczna definicja modułów, obiektów, interfejsów oraz obiektów danych
  • Implementacja: użycie konstrukcji jęzka programowania, wzorce i antywzorce, dobre i złe praktyki
  • Procesy w obrębie projektu: sprawdzenie, czy wszelkie artefakty opisujące tworzenie oprogramowania w konkretnym projekcie są tak samo rozumiane przez wszystkich zainteresowanych, sprawdzenie ciągłości procesów i ich definicji
  • Dokumentacja: aktualność, kompletność, dostępność i jakość dokumentacji
  • Porównanie z istniejącym (meta)modelem architektury

W kolejnych artykułach napiszę o przykładowych narzędziach, które stosowałem w audycie.


29
lis 12

Audyt architektury: wprowadzenie

W kilku artykułach, które zaplanowałem na najbliższy czas, chcę przedstawić metodę przeprowadzenia audytu architektury. Nie mam tutaj na myśli jednak ani formalnego audytu informatycznego ani inspekcji kodu.

Istnieje wiele metod do formalnej inspekcji architektury (ATAM, ASAM, ADR itp.), które jednak wymagają dużej ilości czasu i stawiają wysokie wymagania dokumentacji projektu. Przedstawiona metoda, jako jedno z narzędzi do zapewnienia jakości sytemu, służy do zbadania architektury systemu, jednak nie wymaga aż tak sformalizowanego środowiska. Ponadto pozwala na znalezienie odpowiedzi na konkretne pytania, a nie tylko ocenę architektury pod kątem ogólnych zaleceń i dobrych praktyk. Przykładowo w trakcie audytu architektury można skupić się na następujących zagadnieniach:

  • zachowanie standardów,
  • błędna lub niekompletna specyfikacja modułow lub interface’ów,
  • słabości w dokumentacji lub procesach,
  • i tak dalej…

Wynikiem przeprowadzonego audytu są między innymi opis i ocena aktualnego stanu architektury systemu oraz zbiór zaleceń lub sdefinicja konkretnych działań prowadzących do poprawy sytuacji.