Tworząc oprogramowanie musimy być świadomi jego przeznaczenia. Etap rozpoznania, tworzenia projektu rozwiązania nazywamy analizą, ponieważ to w jego trakcie analizujemy funkcjonalność systemu. Analiza może być wykonywana tylko na początku tworzenia oprogramowania, bądź też iteracyjnie wraz z rozbudową systemu, może mieć różny zakres oraz formę realizacji. W niniejszym artykule główna uwaga skupiona będzie na analizę systemową. Ale zanim do niej dojdziemy sprawdźmy, czy analiza jest potrzebna i jak została uwzględniona w różnych modelach wytwarzania oprogramowania. Porównamy analizę systemową z analizą biznesową oraz sprawdzimy jakie mogą być produkty analizy systemowej.
Czy analiza jest potrzebna?
Często słyszy się, że przygotowanie wymagań, dokumentacji dotyczących danego systemu nie jest potrzebne, a przeprowadzenie analizy to tylko strata czasu. Lepiej od razu zabrać się do implementacji danego rozwiązania i pominąć wcześniejsze kroki. System przecież i tak powstanie, a poza tym będzie szybciej i taniej. Czy na pewno jednak da się opracować jakikolwiek system bez analizy? Przyjmijmy, że mamy najprostszą ze wszystkich możliwych sytuację – tworzymy system sami i to my jesteśmy jego odbiorcami – nie musimy nikogo dopytywać się co tak naprawdę chcemy uzyskać, ani nikomu tego wyjaśniać ponieważ sami to opracujemy. Wydawałoby się, że w tym przypadku analiza jest całkowicie zbędna. Fakt, że tworzenie rozległej dokumentacji w tym przypadku nie jest potrzebne, wymagania określamy sobie sami, a projekt tworzy nam się w głowie. I właśnie czy oby na pewno w tym przypadku nie dokonujemy analizy? Czy sami nie określamy sobie co nasz system ma wykonywać? Może nie mamy wszystkiego do końca ustalonego na samym początku, zanim zabierzemy się do implementacji, ale w trakcie jej realizacji definiujemy sobie co nasz system ma wykonywać, jaką funkcjonalność spełniać, jakie parametry przyjmować i jaki wynik zwracać. Nie jest to zawsze spisane, choć pewnie i tak często pojawiają się notatki, w których fragmenty tej wiedzy zostają zawarte.
W trudniejszych przypadkach, gdy odbiorcą rozwiązania jest ktoś inny niż my sami, musimy już mieć przeprowadzoną obszerniejszą i bardziej sformalizowaną analizę. Musimy dowiedzieć się co dana osoba chce otrzymać oraz jakie wymagania powinien spełniać dany system. Dodatkowo musimy często na tyle dobrze zapoznać się z daną tematyką, aby przewidzieć funkcjonalności systemu, o których odbiorca nam nie powiedział. Niektóre potrzeby mogły wydawać się dla niego zbyt oczywiste, bądź też w danej sytuacji nie wiedział, że są konieczne do spełnienia. W tym przypadku niezbędne jest przeprowadzenie analizy polegającej na określeniu wymagań użytkownika danego systemu.
Dodatkowo sprawa utrudnia się jeśli system jest na tyle skomplikowany, że nie jesteśmy w stanie zrealizować go sami, potrzebny jest do tego większy zespół. Wówczas zespół powinien mieć jak największą i spójną wiedzę, tak aby móc wspólnie zrealizować system, który będzie miał jasno określony cel. Nasz opis funkcjonalności, który mamy w głowie niestety nic tu nie da. Musimy jasno przedstawić funkcjonalność naszego rozwiązania oraz wydzielić jego fragmenty, aby poszczególne osoby mogły je implementować nie utrudniając sobie wzajemnie pracy.
Analiza jest więc konieczna bez względu na to jakiego rozwiązania ma dotyczyć, jednak jej wynik może mieć różną formę i zakres, dostosowane do naszych potrzeb.
Czy analiza jest uwzględniona w różnych modelach implementacji oprogramowania?
W międzynarodowym standardzie do opisywania metod wyboru, implementacji i kontroli cyklu życia oprogramowania – ISO/IEC 12207[1] jednym z podstawowych procesów jest produkcja. Jest to najbardziej rozbudowany proces, w którym produkcja interpretowana jest zarówno jako tworzenie systemu od początku jak i jego modyfikacja. Proces ten składa się z wielu czynności, wśród których wstępne dotyczą analizy wymagań i projektowania. Wśród zadań procesu produkcji określonych w normie można wyróżnić:
- analizę wymagań systemowych,
- projektowanie systemu,
- analizę wymagań software’owych,
- projektowanie architekturalne,
- projektowanie szczegółowe,
- kodowanie i testowanie oprogramowania,
- integrację oprogramowania,
- testy systemu software’owego,
- integrację systemu,
- testy systemu,
- instalację oprogramowania,
- nadzór akceptacyjny oprogramowania.
Istnieje wiele modeli procesów wytwórczych oprogramowania. Możemy tu wyróżnić między innymi:
- Model kaskadowy (Waterfall)
- Model spiralny (Spiral)
- Model przyrostowy (Iterative and Incremental)
- RUP (Rational Unified Process)
- Programowanie zwinne (Agile)
W przypadku modelu kaskadowego czy klasycznego analiza jest jasno wskazanym procesem, jednak w przypadku metod zwinnych nie jest to już takie oczywiste.
Model kaskadowy
Model kaskadowy[2] polega na sekwencyjnym wykonywaniu czynności, które są kolejnymi fazami projektu. Zanim zacznie się kolejna faza poprzednia musi zostać ukończona oraz dokładnie opisana. Pierwsze dwie fazy tego modelu: specyfikacja wymagań i projektowanie obejmują właśnie analizę.
Model kaskadowy
Model spiralny
Model spiralny[3] zakłada cykliczne realizowanie sekwencji działań, które prowadzą do osiągnięcia docelowego rozwiązania. Główną cechą modelu spiralnego jest analiza ryzyka w każdej z faz realizacji rozwiązania. Tworzenie systemu rozpoczyna się od sformułowania głównych wymagań, następnie wykonywana jest analiza realizowanych prac wraz z oceną alternatywnych rozwiązań. W ten sposób tworzone są prototypy systemu.
Model spiralny
Model przyrostowy
W przypadku modelu przyrostowego na początku mamy do czynienia z określeniem wymagań, po których wybierany jest podzbiór funkcji systemu – „przyrost”, dla którego przeprowadzana jest analiza i tworzony projekt. Po implementacji danego zakresu wykonywane jest jego testowanie, po którym dana wersja systemu dostarczana jest do klienta.
Model przyrostowy
RUP
RUP (ang. Rational Unified Process)[4] to iteracyjna struktura procesu tworzenia oprogramowania. W każdej iteracji wytwarzany jest fragment systemu, który jest udostępniany klientowi. Pozwala to na uzyskanie szybkiej informacji zwrotnej i upewnieniu się, że zespół realizujący projekt dobrze zrozumiał wymagania i oczekiwania klienta. Cykl życia RUP oparty jest na przyrostowym modelu cyklu życia oprogramowania, gdzie wyróżnia się cztery fazy: rozpoczęcie, opracowanie, konstrukcja, przekazanie. W każdej iteracji otrzymywane są wyniki prac z sześciu dziedzin:
- modelowanie biznesowe,
- wymagania,
- analiza i projektowanie,
- implementacja,
- testowanie,
- wdrażanie.
Fazy i dziedziny RUP
Programowanie zwinne
Ta grupa metod wytwarzania oprogramowania opiera się na przyrostowym i iteracyjnym modelu cyklu życia oprogramowania. Ze względu na zapis manifestu: „Działające oprogramowanie nad wyczerpującą dokumentację” oraz brak bezpośredniego wskazania roli analityka w przykładowych metodykach zwinnych często uważa się, że proces analizy nie występuje w tego typu metodzie. Oczywiście nie jest to do końca prawda, ponieważ nawet w czystym Agile analiza ma swoje miejsce – wymagania muszą zostać zgromadzone, aby określić jakie zadania mają być realizowane przez zespół i to zespół może być odpowiedzialny za analizę i projektowanie rozwiązania. Pomimo braku jasno zdefiniowanej roli analityka w metodach programowania zwinnego, analityk może się tu odnaleźć pracując poza zespołem bądź jako jego część. W przypadku pracy poza zespołem analityk pracuje iteracyjnie, poza sprintami i dostarcza zespołowi produkty analizy z odpowiednim wyprzedzeniem. Analityk pracujący w zespole wykonuje prace analityczne zgodnie z iteracjami zespołu. Analityk współpracuje z zespołem wytwarza minimum wymaganej dokumentacji, a jego głównym zadaniem jest komunikacja z zespołem.
Analityk w programowaniu zwinnym
Czym różni się analiza biznesowa od systemowej?
Jak to bywa z pojęciami, często mają wiele definicji i są odmiennie rozumiane przez różne osoby. Podobną sytuację mamy również z pojęciami analizy biznesowej i systemowej. Analiza biznesowa i systemowa wchodzą w skład procesu analitycznego, który jest jednym z najważniejszych etapów projektowania systemów. Analiza biznesowa wykonywana jest przez analityków odpowiadających za tworzenie i optymalizację procesów biznesowych. Analizę systemową przeprowadza się po stronie wytwórczej przez analityków modelujących funkcjonalność systemu. W wielu przypadkach rozdzielenie analizy biznesowej od systemowej jest bardzo trudne, ponieważ granica ta zależna jest od danej organizacji i przyjętych w niej praktyk.
Analiza systemowa wymaga zaangażowania w projektowanie i testowanie rozwiązania. Koncentruje się ona w większym stopniu nad tym jak dane rozwiązanie technologiczne powinno działać oraz jakie powinno mieć interfejsy z zewnętrznymi systemami. Analiza systemowa wiąże się z technologią. Ma na celu określenie systemów informatycznych, które mogą umożliwiać osiągnięcie celów biznesowych w danej organizacji. Wykorzystywane mogą być zarówno już istniejące systemy bądź projektowane nowe.
Zadania analizy biznesowej i analizy systemowe
Głównymi zadaniami analizy biznesowej jest analiza procesów biznesowych w organizacji, kontakt z interesariuszami, analiza potrzeb interesariuszy, określenie wymagań biznesowych, wskazywanie rozwiązań lub ulepszeń, dokumentacja i ocena zebranych danych. W przypadku analizy systemowej realizowane są: przekształcenie wymagań biznesowych na techniczne, kontakt z deweloperami, projektowanie systemu dla spełnienia celów biznesowych, opracowanie dokumentacji (specyfikacji, diagramów, schematów blokowych) dla programistów oraz nadzór wdrożenia.
Ze względu na brak jednoznaczności definicji pojęć analizy biznesowej i systemowej istnieją również problemy z interpretacją terminów analityka biznesowego i systemowego. Zgodnie z [5][6] analityk biznesowy to osoba, która wykonuje czynności analizy biznesowej [1][2]. Analitycy biznesowi oraz konsultanci systemów informatycznych współpracują z klientami, aby zidentyfikować i udokumentować wymagania, przeprowadzają biznesowe i techniczne studium, projektują, budują, integrują i wdrażają informatyczne rozwiązania biznesowe, a także dostarczają porad w zakresie strategii, polityki, zarządzania, bezpieczeństwa i dostaw systemów informatycznych[7]. Analityk biznesowy to osoba mająca kompetencje do realizacji działań dotyczących uzgodnień i wspomagania interesariuszy (stron) w zakresie rozwoju oraz funkcjonowania (utrzymania) rozwiązania we wszystkich fazach jego cyklu życia[8]. Natomiast analityk systemowy to osoba prowadząca badania, analizująca i oceniająca wymagania klientów względem IT, procedury lub problemy oraz tworząca i wdrażająca propozycje i rekomendacje, a także planująca i udoskonalająca aktualne lub przyszłe systemy informatyczne[9]. Odmienny zakres obowiązków powoduje, że każda z tych roli wymaga poniekąd odmiennych umiejętności, które zostały przedstawione na poniższym rysunku.
Umiejętności analityka biznesowego i systemowego
Analiza systemowa wymaga bardzo zróżnicowanych umiejętności. Niezbędne są tutaj umiejętności komunikacyjne umożliwiające łatwy kontakt z ludźmi, ale również umiejętności techniczne, które pomogą zweryfikować wykonalność danych funkcjonalności oraz często zaproponować możliwe rozwiązania.
Co powstaje w trakcie analizy systemowej?
Analiza systemowa obejmuje:
- określenie wymagań systemowych, które są rozwinięciem wymagań biznesowych (opracowanych w ramach analizy biznesowej);
- określenie danych wejściowych i wyjściowych systemu;
- weryfikację czy zaproponowane rozwiązanie jest skuteczne oraz opłacalne;
- współpracę z programistami, omówienia opracowanych diagramów i schematów blokowych;
- weryfikację wydajności systemu,
- koordynację testów oraz ich obserwację.
W ramach analizy systemowej uwzględniane są wszystkie produkty powstałe w ramach analizy biznesowej. Zgromadzone i powstałe wymagania biznesowe zostają rozwinięte i uszczegółowione określając wymagania systemowe.
Wymagania biznesowe a wymagania systemowe
Wymagania na system mogą zostać przedstawione w postaci historyjek użytkownika (ang. User Stories). Są to krótkie opisy cech i właściwości systemu, które uspójniają wizję oraz pożądany efekt, który chcemy osiągnąć. Treść historyjki przedstawiana jest najczęściej w postaci następującego schematu:
Jako <aktor> chcę <czynność> aby<wartość>
gdzie:
- Aktor <kto?> – wskazuje konkretny typ użytkownika.
- Czynność <co?> – opisuje co dany aktor zamierza zrobić w systemie.
- Wartość <po co?> – określa sens implementacji, gdyż mówi o dostarczanej wartości.
Dla każdej historyjki musi być zdefiniowane lista kryteriów akceptacji, które określają jakie parametry powinny być spełnione, aby zaakceptować dane User Story.
Jednym z głównych celów analizy systemowej jest opracowanie modelu systemu, który opisuje system z punktu widzenia użytkownika. Modele są budowane w celu lepszego zrozumienia systemu, który jest tworzony. Umożliwia on przedstawienia budowy systemu, specyfikacji struktury systemu oraz jego zachowania, a także udokumentować podjęte decyzje.
Do modelowania procesów biznesowych najczęściej stosowane są notacje: BPMN (ang. Business Process Modeling Notation)[10] i UML (ang. Unified Modeling Language)[11]. BPMN umożliwia tworzenie czytelnych schematów przepływu. Schematy te mogą być tworzone na różnym poziomie od bardzo wysokiego, ukierunkowanego na ludzi po techniczne, przedstawiające np. przepływy procesów IT. UML jest dedykowany do modelowania systemów informatycznych, ale posiada również rozszerzenia notacji dedykowane do modelowania procesów biznesowych.
Podstawowe diagramy UML w analizie biznesowej i systemowej
W przypadku modelowania biznesowego pierwszym krokiem jest zdefiniowanie interakcji między jednostkami znajdującymi się poza systemem, a procesami biznesowymi. Owa interakcja jest dokumentowana w postaci Diagramów Biznesowych Przypadków Użycia. Dodatkowymi diagramami, które mogą zostać wykorzystane do analizy biznesowej są Model Obiektów Biznesowych, Diagram Stanów, Diagram Dziedziny oraz Diagram Aktywności czy Sekwencji. Model Obiektów Biznesowych obrazuje dane dla biznesu, definiuje on stanowiska powołane w organizacji oraz obiekty, które są wykorzystywane, produkowane, badane lub kontrolowane przez pracowników biznesowych. Diagram Dziedziny służy do zestawienia ze sobą określonych i wykorzystywanych w odniesieniu do systemu pojęć. Diagram Stanu określa ciąg stanów przyjmowanych przez dany obiekt w zależności od zdarzeń zachodzących w czasie jego życia.
W przypadku analizy systemowej głównie wykorzystywanym diagramem jest Diagram Przypadków Użycia, który przedstawia funkcjonalność systemu. Dostarcza on abstrakcyjne spojrzenie na system informatyczny. Definiuje on wnętrze systemu – przypadki użycia oraz aktorów i relacje występujące między nimi. W celu przedstawienia szczegółowych informacji odnośnie systemu diagram ten uzupełniany jest o dokumentację, która opisuje scenariusze poszczególnych przypadków użycia. Dodatkowymi podstawowymi diagramami, które służą analizie systemowej są:
- Diagram Aktywności – przedstawiający sekwencję kroków, która jest wykonywana przy modelowaniu fragmentu systemu,
- Diagram Sekwencji – przedstawiający interakcję miedzy obiektami oraz zależności czasowe;
- Diagram Klas – przedstawiający strukturę systemu poprzez ilustracje struktury klas i zależności między nimi.
Dostępnych jest wiele narzędzi, komercyjnych oraz darmowych, które umożliwiają wizualizację modeli przy wykorzystaniu powszechnie stosowanych notacji – UML, BPMN. Najbardziej znanymi narzędziami do modelowania są Visual Paradigm czy Enterprise Architect. Istniejące narzędzia umożliwiają wykorzystanie pełnego zakresu notacji, bądź też pozwalają na stworzenie uproszczonych diagramów procesów, które także mogą zrealizować postawiony przed nimi cel.
Podsumowanie
Analiza systemowa jest procesem, który występuje w każdym modelu implementacji oprogramowania. Może być realizowana tylko na samym początku procesu wytwarzania oprogramowania, bądź iteracyjnie wraz z rozwojem systemu. Rola analityka najczęściej przypisana jest osobie zatrudnionej na tym stanowisku, jednak w przypadku jego braku może być przypisana do poszczególnych osób w zespole odpowiedzialnych za wytworzenie systemu.
Ilość oraz postać opracowywanej w ramach analizy dokumentacji powinna być dostosowana do potrzeb danego projektu. Opracowywana dokumentacja powinna być minimum, które umożliwia zamodelowanie systemu i przedstawienia go zarówno biznesowi jak i programistom odpowiedzialnym za jego implementację. Forma dokumentacji powinna zostać uzgodniona z zespołem, tak aby w jak najprostszy i zrozumiały sposób przedstawiała zakres i funkcjonalność systemu.
***
Bibliografia:
[1] „ISO/IEC/IEEE 12207:2017”. Standards catalogue. International Organization for Standardization. November 2017. Retrieved 21 June 2018.
[2] Royce, Winston W. „Managing the development of large software systems: concepts and techniques”. W Proceedings of Westcon, IEEE CS Press, 1970 r., str. 328-339
[3] Boehm, B. (1986). A spiral model of software development and enhancement. ACM SIGSOFT Software engineering notes, 11(4), 14-24.
[4] Kruchten, Philippe (2004-05-01). The Rational Unified Process: An Introduction. Addison-Wesley. p. 33. ISBN 9780321197702. Retrieved 2014-12-17.
[5] A Guide to the Business Analysis Body of Knowledge®, Version 2.0, International Institute of Business Analysis, Toronto 2009, http://www.theiiba.org
[6] A Guide to the Business Analysis Body of Knowledge®, Version 3 Public Review, International Institute of Business Analysis, Toronto 2014, http://www.theiiba.org.
[7] The National Occupational Classification 2011 (NOC 2011), Human Resources and Skills Development Canada and Statistics Canada, s. 214.
[8] Jerzy Leyk: Role analityka biznesowego – standard ITIL versus BABOK
[9] ISCO-08 Draft definitions, ISCO International Standard Classification of Occupations, July 2009, http://www.ilo.org/public/english/bureau/stat/isco/docs/gdstruct08.doc
[10] https://www.omg.org/spec/BPMN/
[11] https://www.uml.org/what-is-uml.htm
