poniedziałek, 31 marca 2014

Zbliża się publikacja BABOK 3.0

BABOK®, czyli A Guide to the Business Analysis Body of Knowledge® to najlepsze obecnie kompendium wiedzy o dziedzinie analizy biznesowej. Aktualna wersja tego opracowania to 2.0, która została wydana w 2009 roku. Wydawca, czyli IIBA uznał, że po pięciu latach nadszedł czas na odświeżenie tej pozycji. W ciągu ostatniego roku kilkudziesięciu ekspertów i praktyków opracowywało szereg zmian, na podstawie których powstała wersja robocza BABOK 3.0.
Jak zapewnia IIBA na swojej stronie, wiosną tego roku wersja trzecia stanie się dostępna do przeglądu przez całą społeczność analityków biznesowych. Każdy, kto wyrazi taką chęć będzie mógł zgłaszać swoje komentarze do treści. Planuje się, że ten proces potrwa 60 dni, a po jego zakończeniu dostępna będzie finalna wersja dokumentu.

Jak podaje Rick Strempler największą zmianą będzie wprowadzenie tzw. Business Analyst Core Concept Model (BACCM). IIBA zidentyfikował sześć kluczowych pojęć dotyczących analizy biznesowej:
  • Changes
  • Needs
  • Stakeholders
  • Solutions
  • Contexts
  • Value
Idea wprowadzenia tego typu katalogu pojęć nie jest nowa i jest zbliżona na przykład do tematów (themes) zdefiniowanych w metodyce Prince2:
  • Business case
  • Organization
  • Quality
  • Plans
  • Risk
  • Changes
  • Progress
Ważną zmianą jest położenie nacisku na zarządzanie zmianą. Jest to obszar, którego znaczenie wzrosło w ostatnich latach, chociażby za sprawą wzrostu popularności metodyk zwinnych (agile). Choć prawdopodobnie pojęcie zmiany należy rozumieć szerzej - jako kontrolowaną transformację organizacji, niezbędną do realizacji potrzeb biznesowych. Zatem można się spodziewać, że BABOK® będzie się uzupełniał w tym zakresie z TOGAF, którego istotą jest przeprowadzenie organizacji ze stanu bieżącego do stanu pożądanego poprzez wprowadzenie szeregu kontrolowanych zmian.

Niemniej istotną zmianą są obszary wiedzy (knowledge areas) oraz relacje między nimi.
Zmiany w nazwach obszarów wiedzy:

  • Business Analysis Planning and Monitoring - bez zmian
  • Elicitation - będzie: Elicitation and Collaboration
  • Requirements Management and Communication - będzie: Requirements and Design Management
  • Enterprise Analysis - będzie: Situation Analysis
  • Requirements Analysis - będzie: Requirements and Design Analysis
  • Solution Assessment and Validation - bez zmian
  • Underlying Competencies - bez zmian


W wersji 2.0 wyglądało to następująco:
Relationships Between Knowledge Areas
Źródło: BABOK® 2.0, str. 7


W wersji 3.0 będzie to prawdopodobnie wyglądać następująco:
Relationships Between Knowledge Areas
Źródło: http://ig.obsglobal.com/2013/05/babok-version-3-what-business-analysts-can-expect/
Ciekawe wydaje się dodanie w nazwach dwóch obszarów pojęcia design. Według Ricka Stremplera IIBA definiuje design jako "a usable representation of a solution". Może to wskazywać na położenie większego nacisku na wytwarzanie modeli i dokumentacji, które w praktyce pochłania znaczącą część czasu analityka, a w wersji 2.0 opracowania nie zostało dostatecznie mocno zaakcentowane.

Według mnie jednak największą zmianą jest wprowadzenie nowej definicji wymagania. Dotychczasowa definicja bazuje na IEEE 610.12-1990: IEEE Standard Glossary of Software Enginnering Terminology. Nowa definicja jest znacznie prostsza i intuicyjna:
A requirement is a usable representation of a need
Dla osób przygotowujących się do zdobycia certyfikatu CBAP lub CCBA może być również istotna informacja, że po upływie 6 miesięcy od daty publicznego wydania BABOK® - pytania egzaminacyjne zostaną zmienione, aby odpowiadały nowej wersji dokumentu.

sobota, 29 marca 2014

Ogólnie o BABOK

Co to jest BABOK®?

BABOK® jest zaklasyfikowany jako tzw. body of knowledge (BOK). Jest to termin używany w odniesieniu do reprezentacji kompletnego zestawu pojęć, terminów i działań, które składają się w sumie na opis określonej profesji. Termin body of knowledge jest najczęściej używany w odniesieniu do dokumentu, jednakże należy go rozumieć w szerszym zakresie, gdyż za takim dokumentem stoi najczęściej biblioteka innych dokumentów, czy kolekcja dodatkowych informacji, które uzupełniają BOK. 
Body of knowledge nie można nazwać metodyką, gdyż metodyka jest podejściem bardziej teoretycznym, nie opisuje zazwyczaj specyficznych technik, czy metod, które w praktyczny sposób są stosowane w opisywanych procesach.

+Paweł Zubkiewicz w swoim artykule BABOK po polsku - przewodnik po analizie biznesowej napisał:
BABOK® czyli Business Analysis Body of Knowledge jest najbardziej kompletnym zbiorem wiedzy na temat profesji analizy biznesowej. Spisany przez praktyków odzwierciedla aktualnie uznane i szeroko wykorzystywane praktyki analizy biznesowej. Podobnie jak w przypadku innych BOK’ów, czyli Body of Knowledge, jest stale rozwijany przez grupę ekspertów z dziedziny. Przewodnik po analizie biznesowej opisuje dziedzinę profesji analityka biznesowego. Poza opisem najlepszych praktyk, wprowadza taksonomię oraz definiuje umiejętności oraz kompetencje dobrego analityka.
Od siebie mogę tylko dodać, że jest często traktowany jako swego rodzaju "biblia" dla analityków. Wiele osób z branży analitycznej często się powołuje na tę pozycję, choć należy dodać, że niestety zdarza się to bez dogłębnego przestudiowania. Świadczy o tym, choćby fakt, że w chwili obecnej tylko 5 osób w Polsce może się pochwalić certyfikatem CBAP (Certified Business Analysis Professional), który bazuje na wiedzy zgromadzonej w BABOK®.
Zagadnienia związane z analizą biznesową są bardzo rozległe i postrzeganie analizy zależy w dużej mierze od pełnionej roli w organizacji. BABOK® opisuje procesy, zadania i techniki realizowane zarówno po stronie organizacji zlecającej projekty (zamawiającego), jak i po stronie wykonawcy. Poza tym sądzę, że wiele osób, które pracują w rolach, takich jak: Business Systems Analyst, System Analyst, Process Analyst, Consultant, Product Owner, czy innych może nawet nie być świadomym, że to, czym się zajmują to analiza biznesowa. Nierzadko również osoby, które pracują w roli eksperta dziedzinowego (Domain Subject Matter Expert), kierownika projektu, czy testera - wykonują również różne zadania ze sfery analizy biznesowej.

czwartek, 27 marca 2014

Wyświetlanie pakietów na diagramie

Zdarza się czasami, że osoby, które chcą prezentować na diagramach pakiety i powiązania między nimi przychodzą do mnie z pytaniem:
Jak sprawić, żeby na diagramie wyświetlona była również zawartość pakietu?
Aby odpowiedzieć na to pytanie spróbuję najpierw usystematyzować informacje.

Diagram pakietów jest jednym ze strukturalnych typów pakietów UML. Służy do prezentacji pakietów oraz powiązań miedzy nimi. Zaś sam pakiet dostarcza tzw. przestrzeni nazewniczej (ma to znaczenie głównie w inżynierii oprogramowania), jednak dla uproszczenia można traktować pakiet jako kontener grupujący elementy, które dotyczą tego samego obszaru lub są ze sobą powiązane semantycznie.

Pakiety można umieszczać na diagramach dowolnego typu. Jeśli jednak podstawową zawartością diagramu mają być tylko pakiety, wówczas powinniśmy skorzystać z dedykowanego typu: Package Diagram. Zatem z kategorii UML Structural wybieramy Diagram type: Package.


Aby umieścić istniejący pakiet na diagramie wystarczy przeciągnąć go z okna Project Browser. Nowe pakiety umieszczamy na diagramie korzystając z typu elementu Package z palety narzędzi (toolbox).

Domyślnie jednak pakiety na diagramie wyświetlane są w następujący sposób:
Aby diagram prezentował również zawartość pakietów w formie listy elementów konieczna jest zmiana ustawień diagramu. Klikamy zatem prawym przyciskiem myszy na pustym obszarze diagramu, a następnie z menu kontekstowego wybieramy opcję Properties. W oknie tym przechodzimy do zakładki Elements.

W sekcji Show Compartments odnajdujemy checkbox Package Contents i zaznaczamy go, jak na powyższym rysunku. Po naciśnięciu przycisku OK zawartość diagramu zostanie wzbogacona o pożądaną treść.

Na końcu warto jeszcze zadbać o stronę wizualną diagramu i odpowiednio rozmieścić elementy. Warto przy tym pamiętać, że dodanie nowego elementu do pakietu spowoduje automatycznie rozciągnięcie pakietu na diagramie, co może znacznie zaburzyć nasze starania o profesjonalny wygląd diagramu.
Diagram taki po zmianie opcji wyświetlania i ułożeniu jego zawartości może wyglądać, jak na poniższym rysunku.




środa, 26 marca 2014

Zastosowanie UML Profile w Enterprise Architect

W artykule UML Profile opisałem czym jest taki profil oraz do czego może służyć. W tym miejscu chciałbym przybliżyć techniczne aspekty tworzenia, a później wykorzystania takiego profilu.

Tworzenie i późniejsze utrzymanie profilu UML to zadania realizowane w tzw. metamodelu, natomiast wykorzystanie takiego profilu ma miejsce już w docelowym modelu. Aby móc korzystać z profilu konieczne jest jego wdrożenie w formie pliku XML. Zostało to przedstawione w formie graficznej na poniższym rysunku.
UML profile management in Sparx EA

poniedziałek, 24 marca 2014

UML Profiles

W tym artykule opisuję zastosowanie mechanizmu UML Profile. Dowiesz się, do czego można to zastosować i jak samodzielnie przygotować.

Co to jest UML Profile?

UML Profile to mechanizm, dzięki któremu można dostosować język modelowania do potrzeb projektowych. Skrót "UML" w nazwie pojawia, gdyż ten mechanizm został zdefiniowany w ramach samej specyfikacji UML. W tej specyfikacji napisano, że:
The Profiles package contains mechanisms that allow metaclasses from existing metamodels to be extended to adapt them for different purposes.
A zatem, ogólny metamodel UML możemy uszczegółowić poprzez zastosowanie odpowiedniego pakietu, aby w lepszym stopniu odpowiadał specyfice modelowanego problemu, rozwiązania, czy też technologii.
Inaczej mówiąc: profile UML rozszerzają semantykę modelu. Semantyka określa, co należy rozumieć pod przyjętymi oznaczeniami. Czyli profil UML pozwala wprowadzić nowe oznaczenia i nadać im znaczenie, przy czym stosując taki profil nadal jesteśmy zgodni z ogólną składnią UML.

Profil UML bazuje na stereotypach. Oznacza to, że profil zawiera definicje dla określonych stereotypów, które są przypisywane standardowym typom elementów lub relacji UML.

Na przykład dla elementu typu Class można zdefiniować stereotypy:

  • biznes - oznaczający byt mający znaczenie z biznesowego punktu widzenia,
  • web page - oznaczający byt, który jest związany z interfejsem użytkownika,
  • control - oznaczający byt, który kontroluje zachowanie i cykl życia bytów biznesowych, których zmiana inicjowana jest przez użytkownika.
Gdybyśmy mieli model klas pozbawiony tych stereotypów, trudniej byłoby nam się zorientować w znaczeniu tych klas. Jest to szczególnie ważne, gdy czyta się model stworzony przez kogoś innego.

UML Profile to nie jedyny mechanizm rozszerzalności UML, ale jest najbardziej złożony i kompleksowy. Dla każdego ze zdefiniowanych stereotypów możliwe jest również:
  • zmodyfikowanie sposobu wyświetlania elementu na diagramie poprzez przypisanie określonego koloru lub symbolu graficznego,
  • przypisanie określonych wartości etykietowanych, czyli tagged values: składających się ze słowa kluczowego i wartości,
  • dodanie ograniczeń, czyli constraints oznaczających warunki i reguły, zgodnie z którymi obiekt opatrzony danym stereotypem funkcjonuje.


Po co mi UML Profile?

Rozszerzenie semantyki modelu można uzyskać poprzez zdefiniowanie stereotypów (patrz na przykład: Kolorowanie według stereotypów). Taki sposób w większości prostych przypadków sprawdza się doskonale i nie ma potrzeby zawracać sobie głowy profilami UML.
Są jednak przypadki, gdy zastosowanie profili ma sens. Można sobie wyobrazić wiele projektów, gdzie w modelowanie zaangażowanych jest wiele osób, a jednocześnie chcemy zapewnić wysoką jakość modelu. Manualne przypisywanie stereotypu do elementu wiąże się z ryzykiem pojawiania się błędów, np. zamiast stereotypu "web page", ktoś może wpisać "webpage". A przecież może się pojawić konieczność wygenerowania raportu zawierającego kompletną listę elementów o stereotypie "web page". Błędna nazwa stereotypu w jednym przypadku sprawi, że raport nie będzie kompletny.
Bazując tylko na wiedzy teoretycznej o profilach UML trudno sobie zdać sprawę, że ten mechanizm służy również usprawnieniu i ułatwieniu pracy. Otóż, wyobraźmy sobie sytuację, że mamy za zadanie utworzyć model zawierający 100 elementów opatrzonych danym stereotypem, z których każdy powinien mieć przypisane po trzy tagged values wraz z ich wartościami.

Zastosowanie profilu UML w Enterprise Architect pozwala jednym ruchem już w momencie tworzenia elementu na:

  • przypisanie właściwego stereotypu,
  • dodaniu do elementu nazw tagged values wraz z domyślnymi wartościami.
W takim przypadku wystarczy tylko ręcznie nadać elementowi nazwę, zweryfikować poprawność domyślnych wartości tagged values i ewentualnie uzupełnić pozostałe atrybuty elementu, a dopisanie stereotypu oraz dodanie tagged values program EA wykona za nas automatycznie. Korzystając z profilu oszczędzamy czas i minimalizujemy ryzyko pomyłek, czy pominięć.

W jakich przypadkach sprawdza się UML Profile?

Z mojej praktyki wynika, że nie zawsze zastosowanie UML Profile ma sens. Przede wszystkim warto stosować ten mechanizm wtedy, gdy do elementów opatrzonych określonym stereotypem zastosowane będą tagged values
Przykładem zastosowania mogą być diagramy wdrożeniowe (deployment diagrams), które pokazują rozmieszczenie komponentów i obiektów na węzłach. Element typu node można na przykład opatrzyć stereotypami, które odpowiadają fizycznym typom maszyn. Np. "MacBook Pro" lub "HP Proliant BL460c", a dla każdego ze stereotypów przypisać nazwy tagged values
  • Core - oznaczające liczbę rdzeni procesów, które mogą być ważne z punktu widzenia wydajności sprzętu lub warunków licencyjnych,
  • RAM - zawierające wartości odpowiadające ilości wykorzystywanej pamięci, np. 8GB,
  • HDD - zawierające wartości odpowiadające pojemności dysków twardych, np. 500GB, 1TB.
Innym przykładem zastosowania może być zarządzanie wymaganiami, gdy definiujemy kilka różnych kategorii wymagań dla elementu typu requirement. Mogą to być np.:
  • Wymaganie biznesowe,
  • Wymaganie wysokopoziomowe,
  • Wymaganie funkcjonalne,
  • Wymaganie niefunkcjonalne.
Dla takich kategorii wymagań w formie stereotypów można zdefiniować również katalog wartości etykietowanych, np.:
  • Źródło -  dokument, departament lub osobę, która zgłosiła wymaganie,
  • Właściciel - osoba lub departament, która potrzebuje wymagania albo będzie jego biznesowym właścicielem po wdrożeniu rozwiązania na środowisku produkcyjnym.
W artykule Zastosowanie UML Profile w Enterprise Architect zamieściłem szczegółową instrukcję opisującą jak opracować samodzielnie profil oraz pokazałem, jak korzystać z takiego rozszerzenia.