Wprowadzenie
Faza koncepcji rozwiązania jest jednym z kluczowych etapów w procesie wytwarzania oprogramowania, który następuje po fazie inicjacji projektu. Jak to się mówi – „jak sobie pościelesz, tak się wyśpisz” – jakość opracowanej koncepcji rozwiązania bezpośrednio wpływa na powodzenie całego przedsięwzięcia. Niestety, doświadczenie pokazuje, że faza ta jest często zaniedbywana w projektach informatycznych.
O trudnościach w fazie inicjacji projektu, poszukiwaniu celów i sensu wykonywania niektórych projektów napisano już bardzo wiele opracowań. Istotne jest to, że po zakończeniu inicjacji projektu, gdy sposób zaspokojenia potrzeb biznesowych zdefiniowanych w wizji jest zaakceptowany przez decydentów, nadchodzi czas na opracowanie koncepcji rozwiązania.
Definicja koncepcji rozwiązania
Koncepcja rozwiązania to proces, w którym procesy biznesowe muszą „ułożyć się” z szeroko rozumianą architekturą systemów. Jest to etap łączący perspektywę biznesową z perspektywą techniczną, co ma kluczowe znaczenie dla powodzenia projektu.
W tym kontekście należy podkreślić, że sama analiza biznesowa bez konfrontacji jej z architekturą jest niekompletna. Podobnie, budowanie architektury bez uwzględnienia procesów biznesowych ma istotne braki. Dlatego faza koncepcji rozwiązania stanowi pomost między wizją biznesową a szczegółową analizą systemową.
Notacje wykorzystywane w fazie koncepcji rozwiązania
W fazie przygotowania koncepcji rozwiązania można wykorzystać:
- notację UML z diagramem komponentów – do modelowania architektury systemowej
- notację BPMN (Business Process Model and Notation) – do modelowania procesów biznesowych
- notację ArchiMate – dla tworzenia diagramów motywacji i architektury biznesowej
Warunki wstępne do opracowania koncepcji rozwiązania
By zespół analityczno-projektowy mógł skutecznie opracować koncepcję rozwiązania, powinien otrzymać dokument inicjujący, zawierający zestaw informacji wejściowych do analizy. Minimalna zawartość tego dokumentu to:
- potrzeba biznesowa
- cel biznesowy
- opis wstępnie zidentyfikowanych, aktualnie zaangażowanych procesów biznesowych i systemów, które je wspierają
- opis stanu docelowego
Zanim rozpocznie się jakakolwiek dalsza praca, należy mieć dobrze określone dwa kluczowe elementy: potrzebę biznesową i cel. Jeśli nie jesteśmy w stanie określić tych dwóch elementów, wszystkie dalsze działania mogą okazać się bezwartościowe dla organizacji.
Proces przygotowania koncepcji rozwiązania
Przygotowanie koncepcji rozwiązania można podzielić na kilka kluczowych kroków:
Krok 1: Analiza artefaktów wejściowych
Cel: Wstępne zebranie informacji na temat planowanej modyfikacji.
Działania:
- Analiza wizji biznesowej i innych dokumentów wejściowych
- Ocena jakościowa dokumentów pod kątem następujących kryteriów:
- Czy potrzeby biznesowe mają odniesienie do modyfikowanych/tworzonych procesów biznesowych?
- Czy potrzeby biznesowe mają swoich właścicieli, tj. osoby reprezentujące faktycznych beneficjentów postulowanej zmiany?
- Czy cel jest zgodny z koncepcją SMART (prosty, mierzalny, osiągalny, istotny i określony w czasie)?
- Czy potrzeby biznesowe są zgodne ze strategią organizacji?
- Czy potrzeby biznesowe przedstawiają problem/możliwość, a nie sposób rozwiązania?
Wynik: Ocena, czy informacje wejściowe do analizy są wystarczające do prowadzenia dalszych prac projektowych. W przypadku, gdy dokumenty nie spełniają wymaganych kryteriów, są kierowane do uzupełnienia.
Krok 2: Uszczegółowienie celu i potrzeby biznesowej
Cel: Zapewnienie, że każda modyfikacja posiada jasno określony cel, potrzeby i wymagania biznesowe oraz przypisane role interesariuszy i samych interesariuszy.
Działania:
- Analityk tworzy strukturę modelu w repozytorium
- Opracowanie diagramu motywacji, na którym umieszczane są:
- element change (opis zmiany – co chcemy zrobić)
- cel biznesowy
- potrzeba biznesowa
Wynik: Diagram motywacji lub inny dokument przedstawiający powiązania między celami, potrzebami biznesowymi i planowanymi zmianami.
Krok 3: Przygotowanie wymagań biznesowych
Cel: Identyfikacja wymagań biznesowych na podstawie potrzeb biznesowych.
Działania:
- Analiza otrzymanych artefaktów pod kątem zakresu zmian w procesach biznesowych lub systemach
- Wstępna identyfikacja nowych lub zmodyfikowanych wymagań biznesowych
- Wprowadzenie wymagań biznesowych do repozytorium i przeniesienie ich na diagram wymagań
Wynik: Zestaw nowych lub zmodyfikowanych wymagań biznesowych, które należy zrealizować w ramach modyfikacji.
Krok 4: Identyfikacja architektury i procesów biznesowych
Cel: Wskazanie systemów i procesów, które realizują zadania podlegające wprowadzanej zmianie.
Działania:
- Identyfikacja procesów biznesowych, których realizacja będzie zmieniona w wyniku modyfikacji
- Identyfikacja komponentów i aplikacji zmapowanych na procesy biznesowe
- Weryfikacja, czy aktualna funkcjonalność systemów jest wystarczająca do zrealizowania wymagań biznesowych
- Tworzenie zrębów architektury docelowej
Wynik:
- Modele wysokopoziomowych procesów biznesowych AS-IS
- Architektura rozwiązania AS-IS i TO-BE
- Modele przedstawiające integrację systemów
Krok 5: Utworzenie procesu biznesowego AS-IS
Cel: Przygotowanie modelu procesu biznesowego opisującego aktualny stan, na którym będzie bazować dalsza analiza.
Działania:
- Modelowanie procesu biznesowego AS-IS na poziomie 2 lub 3 (w zależności od złożoności modyfikacji) z wykorzystaniem notacji BPMN
- Uzgodnienie zmian biznesowych z właścicielem biznesowym procesu
Wynik: Model procesu biznesowego przedstawiający aktualny stan działania organizacji.
Krok 6: Utworzenie procesu biznesowego TO-BE
Cel: Przygotowanie modelu procesu biznesowego TO-BE opisującego stan docelowy po wdrożeniu zmiany.
Działania:
- Modelowanie procesu biznesowego TO-BE na podstawie procesu AS-IS oraz wymagań biznesowych
- Uzgodnienie modelu z właścicielem biznesowym procesu
- Mapowanie wymagań biznesowych na poszczególne aktywności procesu
- Analiza wpływu nowych wymagań biznesowych na zidentyfikowane wcześniej wymagania
- Analiza procesu biznesowego pod kątem zakresu zmian w komunikacji między jednostkami organizacyjnymi i systemami
Wynik: Model procesu biznesowego przedstawiający docelowy stan działania organizacji po wdrożeniu zmiany.
Krok 7: Przygotowanie dokumentacji
Cel: Opracowanie dokumentu „Koncepcja rozwiązania”.
Działania:
- Zebranie celów, potrzeb biznesowych, wymagań biznesowych, architektury AS-IS i TO-BE
- Uwzględnienie zamodelowanych procesów biznesowych z określonymi wymaganiami biznesowymi
- Opracowanie opisów słownych doprecyzowujących zamierzone zmiany
- Ewentualne przygotowanie dwóch wariantów rozwiązania (dobra praktyka)
Wynik: Dokument „Koncepcja rozwiązania” zawierający kompletny opis planowanej modyfikacji, który po akceptacji pozwala rozpocząć analizę systemową.
Definicje pojęć
W kontekście koncepcji rozwiązania warto wyjaśnić kilka kluczowych pojęć:
Artefakt
Każdy dokument, model, mail, diagram lub inny element o ustrukturyzowanej postaci, który niesie wartość informacyjną i jest wykorzystywany w procesie wytwarzania oprogramowania.
Proces biznesowy
Sekwencja powiązanych ze sobą działań lub zadań, które prowadzą do dostarczenia określonej usługi lub produktu klientowi. Procesy biznesowe opisują, jak organizacja realizuje swoje cele biznesowe.
Proces biznesowy AS-IS
Model procesu biznesowego opisujący aktualny stan działania organizacji, przed wprowadzeniem zmian. Służy jako punkt odniesienia do analizy i planowania zmian.
Proces biznesowy TO-BE
Model procesu biznesowego opisujący stan docelowy – jak proces ma wyglądać po wprowadzeniu planowanych zmian.
Notacja BPMN (Business Process Model and Notation)
Standardowa notacja graficzna używana do modelowania procesów biznesowych, umożliwiająca przedstawienie sekwencji kroków prowadzącej do określonego celu biznesowego. BPMN pozwala wizualizować zarówno czynności wykonywane przez użytkowników, jak i działania systemów.
Wymaganie biznesowe
Określenie definicji obiektu, czynności lub usługi, która wspiera realizację potrzeby biznesowej i pośrednio celu biznesowego projektu lub organizacji. Jest niezbędna do obsługi procesu biznesowego lub świadczenia usługi biznesowej. Wymaganie biznesowe realizuje potrzebę biznesową i jest uszczegółowione poprzez wymagania funkcjonalne i niefunkcjonalne.
Właściciel biznesowy procesu
Osoba, która odpowiada za sposób zorganizowania procesu biznesowego, jego jakość oraz jakość produktów, które ten proces dostarcza. Ma uprawnienia do akceptacji zmian w procesie.
Diagram motywacji
Element notacji ArchiMate przedstawiający cele, potrzeby biznesowe, wymagania i ich wzajemne powiązania. Służy do wizualizacji powodów, dla których podejmowane są zmiany w organizacji.
Architektura biznesowa
Formalna reprezentacja struktury biznesu, zawierająca hierarchię celów i zadań biznesowych organizacji, procesy biznesowe, role i odpowiedzialności oraz przepływ informacji między różnymi częściami organizacji.
Architektura systemów IT
Koncepcyjna struktura definiująca podział systemu informatycznego na komponenty, ich wzajemne relacje oraz zasady projektowania i rozwoju systemu w czasie.
Modyfikacja
Utworzenie nowej lub korekta istniejącej funkcjonalności systemu (albo jego parametrów).
Architektura rozwiązania
Struktura definiująca komponenty, ich właściwości i relacje oraz zasady ich projektowania i rozwoju, które razem spełniają wymagania biznesowe organizacji.
Architekt korporacyjny
Osoba odpowiedzialna za planowanie, projektowanie i utrzymanie ogólnej architektury organizacji (biznesowej, aplikacyjnej, danych i technologicznej) w celu zapewnienia strategicznego dopasowania IT do celów biznesowych.
Architekt IT
Osoba odpowiedzialna za projektowanie, wdrażanie i zarządzanie architekturą systemów informatycznych w organizacji, zapewniając ich spójność, skalowalność i zgodność z wymaganiami biznesowymi.
Interfejs
Punkt styku między dwoma systemami lub komponentami, definiujący sposób komunikacji między nimi.
UML (Unified Modeling Language)
Język modelowania używany do specyfikacji, wizualizacji, konstrukcji i dokumentacji elementów systemów informatycznych. Zawiera różne typy diagramów, w tym diagram komponentów, który przedstawia organizację i zależności między komponentami systemu.
ArchiMate
Otwarty i niezależny język modelowania architektury korporacyjnej, który dostarcza instrumenty umożliwiające opisanie, analizę i wizualizację relacji między domenami biznesowymi i technologicznymi w organizacji.
Usługa aplikacyjna
Element architektury reprezentujący zachowanie komponentu aplikacyjnego, które może być wykorzystywane przez inne komponenty aplikacyjne lub przez użytkowników biznesowych.
Podsumowanie
Koncepcja rozwiązania stanowi krytyczny element w procesie wytwarzania oprogramowania, łączący perspektywę biznesową z technologiczną. Właściwe opracowanie koncepcji rozwiązania pozwala na:
- Zrozumienie rzeczywistych potrzeb biznesowych
- Określenie niezbędnych zmian w procesach biznesowych
- Identyfikację systemów i komponentów wymagających modyfikacji
- Zdefiniowanie architektury docelowego rozwiązania
- Ocenę wpływu zmian na istniejące systemy i procesy
Po akceptacji dokumentu „Koncepcja rozwiązania” można przejść do kolejnego etapu, jakim jest szczegółowa analiza systemowa, w ramach której powstają wymagania funkcjonalne i niefunkcjonalne dla realizowanego systemu.
Warto podkreślić, że skala i formalizm dokumentów tworzonych w fazie koncepcji rozwiązania powinny być dostosowane do wielkości projektu. W mniejszych projektach lub w podejściu zwinnym, dokumentacja może być bardziej zwięzła, ale kluczowe elementy koncepcji rozwiązania powinny być zawsze przemyślane i udokumentowane, nawet jeśli w uproszczonej formie.
Spis treści:
