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.

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.

Analityk czy architekt biznesowy?

W moich dyskusjach z analitykami, którzy są świadomi istnienia czegoś takiego jak architektura korporacyjna pojawiają się czasami następujące pytania:

Kim jest architekt biznesowy?

Czy architekt biznesowy to inna rola niż analityk biznesowy?

Modelowanie perspektyw systemu

Moment rozpoczęcia modelowania systemu można porównać do położenia na biurku czystej kartki papieru. A zatem mamy przed sobą zadanie: zamodelować system oraz puste miejsce, w którym ten model ma powstać. Jak się do tego zabrać?

W pierwszej kolejności warto zastanowić się nad odpowiednim rozplanowaniem elementów składowych modelu. Z pomocą mogą przyjść różnego rodzaju metodyki i ramy (framework). Jednym z nich jest MDA (Model-driven architecture).

Koncepcja MDA bazuje na trzech podstawowych perspektywach systemu:

1. Computation Independent Viewpoint
2. Platform Independent Viewpoint
3. Platform Specific Viewpoint

Dołączanie grafiki do wymagań

Naturą wymagań jest ich forma tekstowa. Każde wymaganie jest formułowane w języku naturalnym. Składa się co najmniej z jednego zdania oznajmującego.

Dobrze, żeby wymaganie miało:

• swój unikalny identyfikator, do którego można referować w innych artefaktach analitycznych, 
• nazwę - która w skrótowej formie prezentuje jego charakter,
• treść - jedno lub kilka zdań; może się składać również z listy numerowanych lub wypunktowań.

A co, jeśli wymaganie dotyczy na przykład ekranu użytkownika lub kształtu raportu? 

Czy należy wówczas w formie tekstowej opisywać położenie przycisku na ekranie? 

Doświadczony analityk wie, że znacznie skuteczniej jest w wymaganiu umieścić prototyp ekranu pokazujący miejsce, gdzie taki przycisk zostanie umieszczony przez programistę.

Mapowanie przypadku użycia

Opracowanie modelu użycia ma na celu udokumentowanie w fazie analizy szczegółowych wymagań dotyczących funkcjonalności budowanego rozwiązania. W tym celu definiowani są aktorzy, którzy wchodzą w interakcję z systemem oraz przypadki użycia, które opisują wykorzystywaną przez nich funkcjonalność.

Jednakże analiza systemów informatycznych oprócz modelu funkcjonalnego obejmuje również inne obszary, takie jak:

• zarządzanie wymaganiami,
• modelowanie procesów biznesowych,
• modelowanie danych (logiczny model danych / model domeny),
• modelowanie interfejsu użytkownika. 

Ponadto analiza nie może istnieć w oderwaniu od innych zadań projektowych, takich jak:

• zarządzanie zakresem projektu,
• zarządzanie ryzykiem,
• zarządzanie problemami,
• zarządzanie zmianą,
• projektowanie,
• implementacja,
• testy.

Częstą praktyką jest chociażby opracowywanie scenariuszy i przypadków testowych przez analityków, które są wykorzystywane przez testerów. Dzieje się tak, gdyż przypadki testowe bazują w głównej mierze na przypadkach użycia, a analityk zna je najlepiej.

Zatem, wskazane jest stworzenie i utrzymywanie określonych powiązań elementów modelu użycia z elementami innych obszarów.

Scenariusze przypadków użycia w EA

W Sparx Enterprise Architect od wersji 8.0 wprowadzono możliwość opisywania scenariuszy przypadków użycia w formie ustrukturalizowanej (Structured Scenario). Wcześniej scenariusz można było tworzyć tylko w postaci sformatowanego tekstu zawierającego ewentualnie listy numerowane. Od dawna możliwe było również opracowanie scenariusza w formie Linked Document dołączonego do elementu typu Use Case.
W tym artykule chciałbym przybliżyć możliwości wykorzystania mechanizmu Structured Scenario. Ten sposób posiada wiele zalet i warto się z nimi zapoznać.

Wykorzystanie Enterprise Architect w analizie biznesowej

Narzędzie, jakim jest Enterprise Architect posiada bardzo szeroki wachlarz możliwych zastosowań. Jednym z nich jest analiza biznesowa. W ramach analizy EA służy głównie do zarządzania i dokumentowania wymagań, modelowania danych, opracowania modelu procesów biznesowych lub modelu użycia.
Wiodącą organizacją, która wyznacza standardy w zakresie analizy biznesowej jest IIBA (International Institute of Business Analysis).
Niedawno brytyjski oddział tej organizacji opublikował raport zatytułowany IIBA UK Business Analysis Survey 2012 Top Line Results. Raport ten zawiera analizę wyników ankiety dotyczącej charakteru pracy analityka biznesowego w Wielkiej Brytanii w 2012 roku. Dodatkowo opracowane wyniki są porównane z wynikami ankiety z poprzedniego roku, dzięki temu powoli zarysowują się określone trendy.
Z mojego punktu widzenia interesujące są statystyki dotyczące wykorzystywanych narzędzi w analizie biznesowej.

Wykorzystanie narzędzi w analizie biznesowej
Źródło: IIBA UK Business Analysis Survey 2012 Top Line Results.

Na pierwszych miejscach pojawiają się narzędzia ogólnego zastosowania, takie jak MS Office, MS Visio, MS Project, czy SharePoint. Nie powinno to dziwić, bo trudno wyobrazić sobie opracowanie dokumentacji bez tego typu narzędzi. Jednak, jak wskazuje IIBA:

Quality Centre (Testing), JIRA (Agile / User Stories), Sparx Enterprise Architect (UML) and BalsamIQ Mock Ups (Mock Ups) are the only non-generalist products which are used by more than 10% of the BA community.

wśród narzędzi, które są dedykowane do pracy projektowej znalazł się Sparx Enterprise Architect.
Oznacza to, że spośród narzędzi do modelowania EA wyróżnia się pod względem wykorzystania spośród takich narzędzi, jak ARIS, IBM Blueworks Live, czy CaseComplete. Podobnie wygląda sytuacja w porównaniu z narzędziami do zarządzania wymaganiami. W tyle zostały takie produkty, jak RequisitePro, czy CaliberRM.

Tendencję wzrostową w zakresie wykorzystania EA pokazuje również następny wykres, który obrazuje zmiany w zakresie wykorzystywania narzędzi w odniesieniu do poprzedniego roku.

Zmiany w wykorzystywaniu narzędzi w analizie biznesowej (2011-2012)
Źródło: IIBA UK Business Analysis Survey 2012 Top Line Results.

Sparx Enterprise Architect wraz z HP Quality Center (Centre) oraz Borland CaliberRM odnotowały największy wzrost.

Można dyskutować o tym, czy zaprezentowane w raporcie wyniki odzwierciedlają prawidłowo rzeczywistość. Raport został opracowany na podstawie wyników ankiety przeprowadzonej tylko w Wielkiej Brytanii. Ponadto zamieszczono informację, że badana próbka to 360 osób.

A może znacie wyniki podobnych ankiet przeprowadzonych w Polsce?

Logowanie - w kontekście przypadków użycia

Niedawno spotkałem się z pytaniem dotyczącym modelowania przypadków użycia i diagramów aktywności. Jeden z użytkowników zastanawiał się nad kwestią umieszczenia na diagramach aktywności wielokrotnie występujących czynności, takich jak logowanie. Jego problem dotyczył tego, czy operacja logowania użytkownika może być zdefiniowana w jednym miejscu w modelu i wstawiana wielokrotnie na różnych diagramach.

Kompletność modelu użycia

Model użycia (use case model) w wielkim skrócie służy do przedstawienia funkcjonalności rozwiązania poprzez zastosowanie przypadków użycia, aktorów oraz relacji pomiędzy nimi.
Z reguły początkujący analitycy dysponują przynajmniej teoretyczną wiedzą o regułach tworzenia modelu użycia. Wraz z każdym zrealizowanym projektem umiejętności te rosną, ale mimo to dostarczany model użycia często nie jest idealny. Warto zatem pokusić się o stworzenie krótkiego podsumowania w tym zakresie.

Import wymagań z Linked Document

Enterprise Architect jest wyposażony w mechanizm, dzięki któremu możliwe jest stworzenie biblioteki dokumentów. Elementy typu Document Artifact (tak naprawdę elementy dowolnego typu, ale na potrzeby tego przykładu skupiam się tylko na elementach tego typu) mogą służyć do przechowywania w modelu kompletnych dokumentów w formacie MS Word.
W tym artykule opisuję jeden z praktycznych sposobów wykorzystania tego mechanizmu.

Opis przykładu

Naszym przykładem będzie realizacja projektu mającego na celu informatyzację biblioteki miejskiej. Do tego celu wykonawca projektu w narzędziu Enterprise Architect tworzy i utrzymuje model. Projekt jest w fazie analizy. W ramach projektu odbywa się szereg spotkań projektowych. Z każdego spotkania sporządzana jest notatka. Zapisy z notatek są istotne zarówno z  punktu widzenia kierownictwa projektu, jak również z punktu widzenia analityków. W trakcie takich spotkań mogą być zgłaszane określone wymagania. Kierownik projektu nalega na uczestników spotkań, żeby każde nowe wymaganie zgłaszane przez klienta było rejestrowane. Oczekiwanie kierownika projektu ma na celu takie zarządzanie wymaganiami, aby każda sygnalizowana potrzeba klienta była odpowiednio zaadresowana. Kierownik projektu chce uniknąć niezręcznych sytuacji, gdy po pewnym czasie, w następnych etapach projektu klient robi wyrzuty typu "Przecież już dawno mówiliśmy Wam o tym..", a analitycy odpowiadają "Nic takiego sobie nie przypominamy..." Znacie z własnego doświadczenia takie sytuacje?

Import wymagań z MS Excel

W artykule Import wymagań z MS Word opisałem prostą metodę usprawniającą kopiowanie treści z edytora tekstu. Zasugerowałem, że można to wykorzystać do importu wymagań. Zaznaczyłem, że ta metoda jest przydatna, gdy dysponujemy bardzo ograniczonym czasem na wykonanie zadania. Jeśli jednak stać nas na solidne przygotowanie warsztatu pracy, spróbujmy wykorzystać VBA (Visual Basic for Applications) w MS Excel i opracujmy swój własny importer wymagań.
Zacznijmy jednak od początku...

Dlaczego mowa o imporcie wymagań?

Dlaczego mechanizmy importu zawężam tylko do wymagań, podczas gdy mechanizmy te są uniwersalne i umożliwiają importowanie elementów dowolnego typu?
Rzeczywiście można importować rozmaitego rodzaju treść do Enterprise Architect. Ja sam importowałem np. przypadki testowe, procesy biznesowe, komponenty aplikacyjne czy też urządzenia. Z punktu widzenia swojej praktyki w wielu projektach zauważam, że najczęściej potrzebny jest jednak właśnie import wymagań.
Wynika to z tego, że zanim wymagania zostaną udokumentowane, konieczne jest ustalenie ich zakresu. Treść wymagań ustala się wraz z klientem podczas spotkań lub poprzez wymianę uwag i odpowiadanie na uwagi w formie pisemnej.
Nie wyobrażam sobie, aby użytkownik z działu merytorycznego korzystał z repozytorium w narzędziu Enterprise Architect do przeglądania i czytania propozycji wymagań. Podobnie nie wyobrażam sobie edycji treści wymagań na spotkaniu bezpośrednio w Enterprise Architect.
Uważam, że do wymiany informacji z klientem, zwłaszcza z użytkownikiem merytorycznym powinny służyć dokumenty w formacie MS Word i MS Excel, gdyż są osoby merytoryczne czują się swobodnie korzystając z tych programów. W takim układzie potrzebne są mechanizmy zarówno do importu treści do modelu Enterprise Architect, jak i mechanizmy eksportu (np. raportowanie), dzięki którym będziemy w stanie "przerzucić" treści w drugą stronę.

Import wymagań z MS Word

W przypadku, gdy w projekcie podjęto decyzję o zarządzaniu i dokumentowaniu wymagań w oparciu o narzędzie Sparx Enterprise Architect zazwyczaj dochodzi do sytuacji, że zestaw wymagań zostaje wypracowany w jakimś innym narzędziu. Najczęściej wymagania dokumentowane są przy użyciu programu MS Word lub MS Excel.
Jest to naturalna sytuacja, gdyż wymagania są opisywane przy użyciu języka naturalnego oraz zachodzi konieczność łatwego komunikowania ich klientowi. Poprawki w treści wymagań często są nanoszone w trakcie spotkań z klientem, bądź przesyłane pocztą elektroniczną. Zastosowanie do tego celu programu MS Word wydaje się najlepszym rozwiązaniem, zwłaszcza gdy w grę wchodzi wykorzystanie trybu rejestracji zmian w MS Word.
Problem zaczyna się, gdy uzgodnioną już treść wymagań należy przenieść do Enterprise Architecta. Gdy wymagań jest niewiele, możliwe jest ich manualne przekopiowanie, jednak w złożonym projekcie wymagań bywa ich kilkaset lub kilka tysięcy. W dodatku w praktyce czas na stworzenie rejestru wymagań w modelu Enterprise Architecta jest bardzo ograniczony, gdyż ważniejszym zadaniem jest zapewnienie określonej wartości merytorycznej artefaktów, niż ich forma.
W niniejszym artykule opisane zostało ułatwienie w przenoszeniu treści wymagań z MS Word. Już na początku chcę wyraźnie zaznaczyć, że nie jest to preferowana przeze mnie metoda. Jeśli to jest możliwe, to zalecam importowanie wymagań przy wykorzystaniu makra w Visual Basicu w programie MS Excel. Opiszę tę metodę przy innej okazji.
Wracając do importu wymagań z MS Word, jej największą zaletą jest prostota. Poza tym nie jest potrzebne opracowywanie jakiegokolwiek narzędzia czy interfejsu do MS Office.