o modelowaniu procesów i systemów 

Poniżej opisane wskazówki to zaawansowane dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać tutaj.

Używaj te same wymagania wielokrotnie
Zaleca się, w miarę możliwości, używanie lub modyfikacje pozyskanych w czasie budowy innych, podobnych lub obejmujących tę samą dziedzinę zastosowań projektów. Oszczędza to koszty i czas ponownego odkrywania wymagań oraz pozwala na uniknięcie wcześniejszych błędów. Ponowne użycie wymagań może prowadzić do wykorzystania np. istniejącego kodu.

Przypisz ryzyko wymaganiom
Zaleca się przeprowadzenie analizy ryzyka dla każdego wymagania lub ich grup. Analiza ta określa prawdopodobieństwo i rodzaj problemów, skutki i środki zaradcze. Ujawnia to wymagania potrzebujące zmian w celu ograniczenia tego ryzyka lub bardziej szczegółowego wyspecyfikowania.

Opracuj słowną parafrazę systemu
W przypadku używania notacji formalnych lub graficznych do prezentacji modelu systemu, przekształć ją także w opis w języku naturalnym. Oszczędza to czas udziałowców systemu weryfikujących ten model i nie narzuca im znajomości notacji.

Zidentyfikuj wymagania ulotne
Powinno się wyróżnić wymagania ulotne, czyli najbardziej podatne na zmiany. W razie możliwości należy przewidzieć jakiego rodzaju to mogą być zmiany. Ich wyodrębnienie wpływa na planowanie i projektowanie systemu, by zredukować te zagrożenia.

Przechowuj odrzucone wymagania
Przechowuj listę wymagań, które zostały odrzucone w fazie analizy i negocjacji oraz dlaczego. Często zdarza się, że proponuje się je bowiem ponownie w czasie późniejszym. Ich przechowywanie może ograniczyć koszty ponownej analizy.

Wyspecyfikuj system przy użyciu metod formalnych
Metody formalne posługują się zapisem matematycznym oraz ustaloną składnią i regułami. Krytyczne części systemu powinny zostać wyspecyfikowane w taki sposób, aby uniknąć niejasności oraz skorzystać z możliwości dowiedzenia poprawności implementacji.

Zbieraj opisy wypadków
Informacje i szczegóły na temat wypadków, które zaszły we wcześniej dostarczonych systemach powinny być zbierane. Unaocznia to pomyłki, które zaszły wcześniej i pomaga w ich uniknięciu w przyszłości.

Wyciągaj wnioski z doświadczeń wypadków
Przy pomocy zebranych informacji o wypadkach należy sprawdzić wymagania funkcjonalne i wyszukać potencjalne zagrożenia bazując na przeszłych doświadczeniach, aby uniknąć podobnych sytuacji.

Dbaj o kulturę bezpieczeństwa w organizacji
Kultura bezpieczeństwa oznacza, że wszyscy w organizacji są świadomi roli jaką pełni bezpieczeństwo i czuje się odpowiedzialny jej zapewnienia. Łatwiej jest wtedy o ulepszanie dotychczas stosowanych procesów.

Nigdy się nie zastanawiałem nad etyką w procesie wytwórczym oprogramowania aż do dziś kiedy natrafiłem na artykuł, którego autorami są Maria Ganzha i Stanisław Szejko. Tekst jest dość ciekawy gdyż porusza nowe obszary procesu wytwórczego oprogramowania, które wykraczają poza tradycyjnie stosowaną podejście stosowane w inżynierii  oprogramowania.

Zainteresowanych odsyłam do artykułu: http://www.e-informatyka.pl/article/show/493

Poniżej opisane wskazówki to średniozaawansowane dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać tutaj.

A. Pozyskiwanie wymagań

Poszukaj ograniczeń narzucanych przez dziedzinę problemu
Domena budowanego systemu narzuca często dodatkowe wymagania, wynikają one z obowiązujących wymogów, przepisów oraz ograniczeń dziedziny. System musi je brać pod uwagę i spełniać. Gromadzenie tych ograniczeń może być przydatne przy budowie innego systemu z tej samej dziedziny.

Przechowuj uzasadnienia wymagań
Uzasadnienie wymagania podsumowuje przyczyny wyspecyfikowania wymagania oraz wyjaśnia adresowany problem i sposób jego rozwiązania. Uzasadnienie przyspiesza zrozumienie wymagania oraz pomaga w ocenie wpływu zmian ma wymaganie.

Zbieraj wymagania z wielu punktów widzenia
Ważnym elementem dla pozyskiwania wymagań jest identyfikacja punktów widzenia (ang. viewpoint) na system. Takie osobne punkty widzenia mogą mieć użytkownicy końcowi, managerowie czy też ograniczenia dziedziny systemu. Identyfikacja ich pomaga w kategoryzacji wymagań oraz wyszukiwaniu ważnych. 

Prototypuj trudno zrozumiałe wymagania
Prototyp jest demonstracją działania systemu zbudowaną w celu ukonkretnienia wymagań udziałowców systemu. Jest to szczególnie istotne w przypadku niejasnych i trudnych do określenia wymagań dotyczących np. interfejsu użytkownika.

Stosuj scenariusze użycia
Scenariusz to zapis przykładowej interakcji użytkownika z systemem. Wskazywane są w nim oczekiwania użytkowników co do systemu. Pozwala to na łatwiejsze pozyskiwanie wymagań i żądanej funkcjonalności od użytkowników.

Zdefiniuj procesy operacyjne
Systemy komputerowe zazwyczaj mają na celu wspomaganie pewnych procesów zachodzących w organizacjach. Należy więc zdefiniować te procesy, aby lepiej zrozumieć budowany system. Prowadzi to do łatwiejszej identyfikacji udziałowców i samych wymagań.

B. Analiza i negocjacja wymagań

Klasyfikuj wymagania używając podejścia wielowymiarowego
Zaleca się klasyfikowanie wymagań, aby znaleźć związane powiązania pomiędzy nimi. Najlepiej używać wiele sposobów kategoryzacji równolegle. Taki sposób nazywa się wielowymiarowym. Pozwala to znaleźć podobieństwa i konflikty pomiędzy wymaganiami oraz pomaga w śledzeniu propagacji zmian i znajdowaniu brakujących wymagań.

Użyj macierzy interakcji, by wykryć nakładające się wymagania i konflikty
Macierz interakcji posiada w wierszach i kolumnach wymagania, zaś na przecięciach relacje pomiędzy danymi dwoma wymaganiami. Może to być konflikt, zazębienie lub brak związku. Macierz taka wymusza analizę związków pomiędzy wszystkimi wymaganiami i stanowi dobry obiekt do negocjacji wymagań.

C. Opisywanie wymagań

Specyfikuj wymagania ilościowo
W miarę możliwości wymagania (zazwyczaj niefunkcjonalne) powinny zawierać konkretne, mierzalne wartości opisywanych atrybutów. Przekazuje to precyzyjne informacje dla wykonawców oraz stanowi podstawę do testów akceptacyjnych systemu.

D. Modelowanie systemu

Użyj metod strukturalnych do modelowania systemu
Metody strukturalne to zbiór notacji, wskazówek oraz reguł definiowania modelu systemu. Tak zdefiniowane modele mogą być uzupełnieniem specyfikacji wymagań, ustandaryzowują dokumentację modeli oraz ułatwiają przejście to projektu systemu.

Użyj słownika danych
Wszystkie nazwy używane w modelach systemu powinny zostać umieszczone w słowniku wraz z opisem i innymi informacjami. Pozwala to ustalić wspólne nazewnictwo, szczególnie w wieloosobowych zespołach oraz wspomaga śledzenie propagacji zmian.

Udokumentuj powiązania pomiędzy wymaganiami udziałowców systemem
Zawsze powinno się udokumentować powiązania pomiędzy opisem słownym wymagań uzyskanym od udziałowców a szczegółowymi modelami specyfikującymi system. Ułatwia to śledzenie propagacji zmian oraz sprawdzanie modeli i powiązanych z nimi wymagań.

E. Weryfikacja wymagań

Skonstruuj prototyp do animacji wymagań
Stwórz prototyp systemu, aby zademonstrować pozyskane wymagania i uzyskać ich akceptację przez udziałowców systemu lub wskazówki dotyczące zmian. Prototyp pomaga udziałowcom w wizualizowaniu wymagań oraz zapobiega niejasnościom w wymaganiach.

Napisz szkic podręcznika użytkownika
Na podstawie specyfikacji systemu napisz szkicowy podręcznik użytkownika zawierający opis wszystkich aspektów funkcjonalności z uwzględnieniem założeń dotyczących interfejsu użytkownika. Pomaga to ujawnić możliwe problemu z użytkowaniem systemu.

Zaproponuj testy dla wymagań
Dla każdego wymagania zaproponuj jeden lub wiele testów sprawdzających, czy system spełnia dane wymaganie. Często ujawnia to brakujące informacje w wymaganiach a także pomaga w zaprojektowaniu i zaplanowaniu właściwych testów systemu.

F. Zarządzanie wymaganiami

Użyj bazy danych do zarządzania wymaganiami
Zaleca się zastosowanie bazy danych do przechowywania wymagań w miejsce formy papierowej. Baza taka jest łatwiejsza do utrzymywania, aktualizacji i przeszukiwania oraz utrzymywania informacji o powiązaniach. Dostęp i aktualizację może dokonywać wiele osób jednocześnie.

Zdefiniuj reguły zarządzania zmianami
Powinny zostać zdefiniowane jasne reguły proponowania, analizowania i akceptowania zmian w wymaganiach. Po uwzględnieniu zmiany tworzona jest nowa wersja danego wymagania. Zdefiniowanie tych reguł daje udziałowcom mechanizm wnoszenia poprawek, przy jednoczesnym uwzględnieniu i zaplanowaniu kosztów z tym związanych.

Zidentyfikuj globalne wymagania systemowe
Globalne wymagania systemowe określają istotne i pożądane cechy systemu jako całości. Nie są one związane z modułem czy podsystemem. Są też one dlatego najbardziej kosztowne do zmiany i wymagają konsultacji z wszystkimi udziałowcami. Ich znajomość pozwala na przewidzenie i zaplanowanie kroków wymaganych w przypadku zmian.

G. Systemy krytyczne

Zidentyfikuj i zanalizuj zagrożenia
Zagrożenie to stan systemu mogący doprowadzić do wypadku. W przypadku systemów krytycznych wymagane jest zebranie zagrożeń, ich możliwych przyczyn i konsekwencji. Stanowi to pierwszy krok w zapewnianiu bezpieczeństwa dla takich systemów.

Wywiedź wymagania bezpieczeństwa z analizy zagrożeń
Na podstawie analizy zagrożeń powinno się zawsze wprowadzić wymagania funkcjonalne unikania lub ograniczania skutków wypadków. Postępowanie zgodnie z tymi regułami podnosi znacznie bezpieczeństwo systemu.

Sprawdź wymagania funkcjonalne wobec wymagań bezpieczeństwa
Ciągle sprawdzaj wymagania funkcjonalne, czy nie wpływają na powstawanie nowych zagrożeń i czy nie rodzą się konflikty z wymaganiami zabezpieczającymi. Ma to na celu podniesienie bezpieczeństwa systemu i wyszukanie konfliktów wymagań.

Poniżej opisane wskazówki to podstawowe dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać tutaj.

A. Dokument specyfikacji wymagań

Zdefiniuj standardową strukturę dokumentu
Dokument wymagań powinien mieć ustandaryzowaną w danej organizacji strukturę. Ma to ułatwić i przyspieszyć czytelnikom zaznajamianie się z dokumentem ze względu na znajomość struktury i rozkładu treści.

Wyjaśnij jak korzystać z dokumentu
Dokument specyfikacji wymagań powinien zawierać sekcję wyjaśniającą sposób korzystania z dokumentu przez różne grupy adresatów. Powinny zostać wymienione sekcje przeznaczone dla poszczególnych grup, co ułatwi im i przyspieszy zapoznanie się z treścią dokumentu.

Załącz podsumowanie wymagań
Dokument specyfikacji powinien zawierać rozdział podsumowujący założenia systemu i prezentujący podstawowe jego wymagania. Pozwala to czytelnikom uzyskać szerszy obraz systemu i umożliwia odwoływanie się do później szczegółowo zdefiniowanych wymagań oraz przyspiesza ich wyszukiwanie.

Odnieś się do analizy biznesowej
Dokument specyfikacji powinien zawierać rozdział uzasadniający potrzebę budowy systemu i odwołujący się do celów organizacji dla której jest on przeznaczony. Pomaga to w uzasadnianiu wystąpienia pewnych wymagań oraz pozwala na ocenę zmian wprowadzanych w wymaganiach w odniesieniu do celów organizacji.

Zdefiniuj specjalizowane terminy
Dokument powinien zawierać słownik terminów specjalistycznych i specyficznych dla domeny systemu. Pomaga to w uniknięciu nieporozumień terminologicznych zarówno wśród autorów jak i czytelników. Poszerza także krąg potencjalnych czytelników.

Zadbaj o czytelną strukturę dokumentu
Dokument powinien mieć czytelną i jasną strukturę pozwalającą ograniczyć czas potrzebny na przegląd dokumentu i znajdowanie w nim informacji. Podnosi to ogólną efektywność osób korzystających z dokumentu. Zaleca się m.in. używanie szerokich marginesów, spójnych nagłówków, list i wypunktowań oraz diagramów w miejsce opisów słownych.

Pomóż czytelnikowi znaleźć informacje
Aby przyspieszyć korzystanie z dokumentu przez cały przebieg projektu powinien on zawierać indeks oraz spis treści, tabel, rysunków itp. Pomaga to znacznie w znajdowaniu potrzebnych informacji i zwiększa produktywność jego użytkowników.

Spraw, by dokument był łatwy do zmian
Dokument powinien być łatwy do zmian dla jego użytkowników i nie wymagać przebudowy i ponownego rozpowszechnienia w całości. Zapewnić to powinien zarówno sposób napisania jak i publikacji. Ogranicza to koszty wynikające z rozpowszechniania oraz opóźnień.

Oceń wykonalność systemu
Ocena wykonalności systemu powinna zostać przeprowadzona przed pozyskiwaniem wymagań, aby ocenić możliwość i wykonalność implementacji systemu oraz określić jej opłacalność. Może się okazać bowiem, że system nie spełnia tych warunków i jego realizacja niesie duże ryzyko niepowodzenia.

B. Pozyskiwanie wymagań

Bądź wyczulony na czynniki organizacyjne i polityczne
Czynniki specyficzne dla organizacji i strategiczne mogą mieć wpływ na przebieg pozyskiwania wymagań. Ich identyfikacja może pomóc w wyróżnieniu ważnych źródeł wymagań i samych wymagań systemowych.

Zidentyfikuj udziałowców systemu i skonsultuj się z nimi
Udziałowcami nazywamy wszelkie osoby zaangażowane w tworzenie systemu i te w przyszłości czerpiące z niego korzyści. Identyfikacja tych osób może pomóc w pozyskiwaniu wymagań ujawniając potencjalne ich źródła.

Przechowuj źródła wymagań
Źródła wymagań określają powiązanie z informacją, na podstawie której uzyskano wymaganie. Źródłem mogą być udziałowcy systemu, korespondencja, standardy jakości, dokumentacja techniczna i inne. Przechowywanie źródeł przyspiesza ponowne konsultacje przy zmianach wymagań.

Zdefiniuj środowisko działania
Zdefiniowanie środowiska operacyjnego, czyli docelowej platformy sprzętowej i programowej, ale również innych systemów komunikujących się i wykorzystujących budowany system pozwala na ograniczenie odtworzenie tych warunków w testach a poza tym umożliwia ujawnienie wymagań narzucanych przez systemy zewnętrzne.

Użyj celów biznesowych przy pozyskiwaniu wymagań
Cele biznesowe to abstrakcyjne i ogólne cele stawiane budowanemu systemowi, wymagane aby zadowolić zleceniodawcę. Spełnienie ich jest podstawowym warunkiem użyteczności systemu i stanowi bazę do specyfikowania wymagań.

C. Analiza i negocjacja wymagań

Zdefiniuj granice systemu
Granice systemu są definiowane przez ograniczony zbiór wymagań systemowych. Należy oddzielić od nich wymagania procesów związanych z systemem i inne będące poza zakresem systemu. Eliminuje się w ten sposób niejasności w późniejszym procesie analizy wymagań.

Użyj list kontrolnych do analizy wymagań
Lista kontrolna powinna zawierać pytania sprawdzające problemy napotkane w dotychczasowym doświadczeniu analizy wymagań. Zweryfikowanie każdego wymagania przy pomocy takiej listy zapobiega omyłkom i przyspiesza proces analizy wymagań.

Udostępnij oprogramowanie do wspomagania negocjacji
Proces analizy i negocjacji wymagań powinien być wspomagany przy użyciu np. poczty elektronicznej i elektronicznych tablic ogłoszeń lub nawet systemów konferencyjnych i wspomagających pracę grupową. Celem jest zapewnienie ciągłego dialogu udziałowców i analityków, aby uniknąć nieporozumień, przy jednoczesnym ograniczeniu kosztów spotkań.

Zaplanuj postępowanie w przypadku konfliktów i ich rozwiązywanie
W każdym projekcie należy oczekiwać konfliktów pomiędzy wymaganiami i należy się na to z góry przygotować planując spotkania negocjacyjne z udziałowcami systemu w celu ustalania kompromisów. Takie spotkania skracają czas fazy analizy wymagań.

Nadaj priorytety wymaganiom
W czasie analizy i negocjacji należy nadać wymaganiom priorytety zgodnie z ich ważnością dla udziałowców i dla powodzenia systemu jako całości. Wyróżnić można w ten sposób najważniejsze wymagania i na nich skoncentrować negocjacje.

D. Opisywanie wymagań

Zdefiniuj szablony do opisywania wymagań
Szczegółowy opis wymagań powinien być budowany z wykorzystaniem standardowego szablonu zawierającego miejsce na wszystkie istotne informacje. Wymagania są łatwiejsze do czytania i do pozyskiwania. Unika się możliwości ominięcia ważnych informacji.

Użyj prostego i ścisłego języka
Jeżeli używany jest opis słowny wymagania powinien on być wyrażony przy pomocy prostego i ścisłego języka  z wykluczeniem skomplikowanych zdań i niejasnego słownictwa. Ułatwia to szybkie czytanie i zrozumienie wymagań a przez to ogranicza koszty.

Użyj diagramów w odpowiedni sposób
Diagramy powinny być włączone w opis wymagania, aby wyrazić informacje strukturalne, powiązania pomiędzy elementami opisu lub opisać sekwencje zdarzeń. Są one łatwiej i szybciej zrozumiałe niż opis słowny. Mogą być także powtórnie używane w przyszłości.

Uzupełnij opis słowny wymagań innymi opisami
Niektóre wymagania najlepiej jest opisywać przy pomocy równań matematycznych, notacji projektowych lub nawet języków programowania. Opis taki nie powinien jednak zastępować, a jedynie uzupełniać opis słowny, czyniąc go bardziej ścisłym.

E. Modelowanie systemu

Opracuj komplementarne modele systemu
Aby nie komplikować modelu systemu, lepiej jest go podzielić na mniejsze modele prezentujące różne jego aspekty. Wymusza to analizę z uwzględnieniem tych różnych aspektów, ujawnia przeoczenia oraz ułatwia komunikację z udziałowcami reprezentującymi określony punkt widzenia na system.

Zamodeluj otoczenie systemu
Aby lepiej zrozumieć wymagania, dobrze jest zamodelować otoczenie systemu, czyli inne systemy komunikujące się z budowanym. Wymusza to wyspecyfikowanie sposobu tej komunikacji oraz wskazuje możliwości wykorzystania systemów zewnętrznych. Pomaga także czytelnikom w zrozumieniu związku z wspomaganymi procesami biznesowymi.

Zamodeluj architekturę systemu
Zawsze powinno się zamodelować architekturę systemy ukazującą w jaki sposób system jest podzielony na podsystemy i w jaki sposób przebiega komunikacja pomiędzy podsystemami. Pomaga to w podziale wymagań oraz identyfikacji często stwarzających problemy wymagań dotyczących kilku podsystemów.

F. Weryfikacja wymagań

Sprawdź, czy dokument jest zgodny z twoim standardem
Zanim dokument wymagań zostanie rozpowszechniony powinien zostać sprawdzony pod względem zgodności z przyjętym standardem dokumentów. Oszczędza to czas osób później przeglądających, gdyż mogą się one skoncentrować na stronie merytorycznej dokumentu.

Zorganizuj formalne przeglądy wymagań
Wymagania systemowe powinny być regularnie przeglądane przez wyznaczoną grupę osób. Spotykają się oni, aby dyskutować problemy związane z wymaganiami i ustalać sposoby radzenia sobie z nimi. Spotkanie takie powinno się koncentrować na samych problemach a nie na odpowiedzialności za nie.

Użyj wielodyscyplinarnych zespołów do przeglądu wymagań
Do przeglądu wymagań najlepsze są zespoły złożone z przedstawicieli różnych grup udziałowców i ekspertów. Zapewnia to różnorodność punktów widzenia oraz dokładność i wszechstronność przeglądu wymagań. Udziałowcy czują się w ten sposób zaangażowani w proces specyfikacji wymagań oraz bardziej otwarci na zmiany.

Zdefiniuj listy kontrolne dla wymagań
Listy kontrolne pozwalają na uporządkowanie weryfikacji wymagań oraz koncentrację uwagi osób sprawdzających na najbardziej krytycznych atrybutach wymagań. Pozwalają także wdrożyć niedoświadczone osoby, np. użytkowników końcowych w proces weryfikacji.

Przypisz wymaganiom identyfikatory
Nadaj wymaganiom identyfikatory lub numery, aby łatwiej się było do nich odwoływać z innych części specyfikacji wymagań lub innych dokumentów. Wspomaga to proces śledzenia propagacji zmian i ułatwia stosowanie narzędzi automatyzujących zarządzanie wymaganiami.

G. Zarządzanie wymaganiami

Zdefiniuj reguły zarządzania wymaganiami           
Reguły zarządzania wymaganiami powinny definiować cele i procedury tego procesu oraz standardy do podążania. Wskazują one osobom zaangażowanym w projekt co i w jaki sposób powinno być wykonywane. Uniezależnia się w ten sposób od indywidualnej wiedzy.

Zdefiniuj reguły śledzenia propagacji zmian
Część reguł zarządzania wymaganiami stanowić powinny informacje dotyczące zakresu i sposobu śledzenia propagacji zmian. Powinny one zawierać informacje jak znaleźć powiązania pomiędzy wymaganiami oraz pomiędzy wymaganiami a projektem, dokumentacją itp. Wpływają one na kontrolę jakości i kosztów i ułatwiają zmiany w systemie.

Utrzymuj podręcznik śledzenia propagacji zmian
Dodatkiem do dokumentu specyfikacji wymagań powinien być podręcznik śledzenia propagacji zmian. Zawiera on informacje o zastosowanych regułach śledzenia oraz same informacje o powiązaniach wymagań i innych elementów. Zebranie tych informacji w jednym miejscu ułatwia zmiany i aktualizację oraz przyspiesza dostęp do nich.

H. Systemy krytyczne

Utwórz listę kontrolną dla wymagań bezpieczeństwa
Powinna zostać sporządzona lista kontrolna specyficzna dla dziedziny zastosowań systemu, aby sprawdzić kompletność specyfikacji wymagań. Jeżeli istotne jest bezpieczeństwo i niezawodność, ta lista też powinna się koncentrować na tych atrybutach. Uniknąć w ten sposób można ominięcia istotnych dla tych cech systemu wymagań.

Zaangażuj osoby zewnętrzne w proces zatwierdzania wymagań
Należy zawsze włączyć zewnętrznych ekspertów, nie biorących udziału w pozyskiwaniu i negocjacji wymagań, w proces zatwierdzania wymagań dla systemów krytycznych. Wnoszą oni świeży punkt widzenia i nie mają uprzedzeń wyniesionych z poprzednich faz.

O korzyściach z modelowanie procesów biznesowych mówi sie bardzo wiele. Moim zdaniem najważniejsze profity to:

• poprawa efektywności pracy przez ustandaryzowanie procesu
• podniesienie jakości procesów
• skrócenie czasu realizacji procesów
• znalezienie błędów i wąskich gardeł w procesach
• uzyskanie możliwości oszacowania kosztów procesów biznesowych

Ponadto analiza procesów biznesowych może stać się podstawą do wdrożenia dedykowanych systemów IT co z kolei pozwala także na:

• zmniejszenie kosztów raportowania
• zmniejszenie kosztów dystrybucji dokumentów

Oba wyżej wymienione działania nie tylko podniosą komfort pracy i w perspektywie czasu przyniosą zwroty z poniesionych kosztów na wykonanie modeli ale także zwiększają satysfakcję klientów oraz poprawiają pozycję rynkową firmy. Ponadto mapa biznesu w postaci modeli jest niezastąpiona w trakcie reorganizacji firmy oraz może stanowić element zarządzania jakością.

Czasami dostaję pytanie: Ile kosztuje modelowanie w UML? Moja odpowiedź brzmi: Dużo, ale koszty się zwracają z zyskiem. Skąd ten zysk skoro modelowanie w UML to czas ludzi, którzy zamiast pisać kod siedzą i modelują a od tego kodu nie przybywa. Moi rozmówcy mają obawy, że to korzystanie z UML wydłuża proces budowy oprogramowania. Pozornie tak i pewnie, można zacząć od razu budować kod (wiele firm działa tak z powodzeniem do dziś), tylko dlaczego jak budujemy dom to najpierw go planujemy? Przecież można włączyć betoniarkę, kupić cegły i do dzieła. Ale my najpierw planujemy dom, może po to by się nie zawalił, może po to by spełniał nasze oczekiwania. Potem jak zatwierdzimy plany to w trakcie budowy są oczywiście pewne zmiany (przestawiamy ścianki, zmieniamy wysokość okna itd. itp.), ale nikt nie burzy wszystkiego i nie zaczyna od nowa. W pisaniu kodu często bywa tak, że albo oddajemy źle napisany komponent (o ile w miarę działa), albo piszemy od nowa (by w miarę działał). Oszczędność o której pisałem na początku to czas jaki tracimy na poprawianie (lub pisanie od nowa) źle funkcjonujących komponentów.  Dziwne jest czasem dla mnie to, że przy budowie domu zatrudnia się obligatoryjnie architekta który go planuje (lub kupuje gotowy projet), a przy budowie oprogramowania, które jest dużo bardziej skomplikowane oszczędza się na projekcie.  Na szczęście moi klienci już dojrzeli korzyści z modelowania i dzięki temu mam co robić bo modelowanie w UML nie musi być ani czasochłonne, ani trudne i kosztowne. 

Panuje powszechna opinia, że modele wyrażone w języku UML są niezrozumiałe i nie wiadomo jak go stosować. Problem czytelności diagramów jest tym bardziej istotny, gdy dokumentacji (jakże pieczołowicie) wykonanej w UML nie umie przeczytać Klient. Tak to problem, z którym czasem się spotykam. Wtedy zanim Klient zobaczy wartość modelowania  pozwalam nazywać poszczególne elementy notacji tak jak je nazwał klient przy zachowaniu odpowiedniego znaczenia tego elementu. I tak przykładowo aktor na początku nazywany jest ludzikiem z czasem jest nazywany systemem lub użytkownikiem by potem gdy klient wdraża już UML?a na stałe nazwać go poprawnie aktorem. Oczywiście pilnuję by znaczenie aktora na diagramach przypadków użycia nie zostało zniekształcone.  Ta metoda sprawdziła mi sie w u większości klientów, którzy nie używali UML. Niestety nie u wszystkich

Na koniec została sprawa jak stosować UML i kiedy? Nie ma jednoznacznej odpowiedzi na ten temat, gdyż użycie języka UML zależy od specyfiki realizowanego projektu, etapu na którym się ten projekt znajduje, czy znajomości języka UML przez różne osoby zaangażowane w dany projekt. Z tego też powodu potrzebne jest pewne doświadczenie. Ale jak zdobyć to doświadczenie, gdy książki mówią o notacji UML a nie o tym jak go stosować a przykłady z Internetu też są banalne? Na początek proponuję konsultacje u doświadczonej osoby, która ma za sobą kilka projektów z wykorzystaniem UML. Byłoby rewelacyjnie gdyby taka osoba nadzorowała nasze prace – była takim Aniołem Stróżem UML. Myślę, że takie spotkania dadzą więcej niż nawet kilkudniowe szkolenie.

Miłą niespodzianką dla mnie okazał się fakt iż mój blog czyta osoba, którą uważam za ekspert w dziedzinie modelowania. Tą osobą jest Jarosław Żeliński (http://it-consulting.pl/). Cieszy mnie to tym bardziej, że moje wpisy stały się pożywką do podjęcia dyskusji o UML i BPMN. Zainteresowanych odsyłam do wpisu Modelowanie procesów biznesowych w UML czy BPMN? oraz do naszej krótkiej dyskusji na ten temat.

Model Biznesowych Przypadków Użycia jest modelem, który prezentuje funkcje biznesowe organizacji.

Celem Modelu Biznesowych Przypadków Użycia w ramach WMB jest prezentacja funkcji, jakie realizowane są w organizacji zarówno z perspektywy wewnętrznej i zewnętrznej. Ponadto Model Biznesowych Przypadków Użycia wskazuje na interakcję organizacji z otoczeniem.

Model Biznesowych Przypadków Użycia jest używany przez interesariuszy i analityków procesów biznesowych, aby zrozumieć, w jaki przedsiębiorstwo wchodzi w interakcje z otoczeniem, a także przez osoby projektujące oprogramowanie, aby zapewnić kontekst rozwoju oprogramowania. Model Biznesowych Przypadków Użycia jest bazą służącą do planowania iteracji.

W WMB składowe Modelu Biznesowego Przypadku Użycia to:

• systemy biznesowe (pakiety biznesowe) – reprezentujące strukturę organizacji,
• pracownicy biznesowi (w odróżnieniu od innych metodyk),
• aktorzy biznesowi,
• biznesowe przypadki użycia
• relacje,
• diagramy: pakietów i biznesowych przypadków użycia,

Warto także zamieścić opis tekstowy, który służy jako zwięzłe wprowadzenie do modelu.

Biznesowy Przypadek Użycia reprezentuje funkcje dostarczane przez organizacje. W ramach WMB funkcje te są ciągiem działań (składających się scenariusz procesu biznesowego), które organizacja wykonuje, który daje widoczny wynik o wartości określonego aktora lub pracownika biznesowego.

Biznesowy Przypadek Użycia opisuje proces biznesowy z punktu widzenia zewnętrznej, dodanej wartości. Biznesowe przypadki użycia to procesy biznesowe, które przecinają granice organizacji, obejmując ewentualnie partnerów i dostawców, aby zapewnić wartość dodaną organizacji. W ramach WMB Biznesowy Przypadek Użycia jest (skierowany na proces) specyfikacją zachowania przedsiębiorstwa w reakcji na interakcję między przedsiębiorstwami oraz aktorami biznesowymi oraz pracownikami biznesowymi.

przeczytaj pozostałą część »