Metoda analizy i specyfikowania wymagań na oprogramowanie

Analiza systemowa organizacji: opracowanie
modelu jej działania, cel i szukanie rozwiązania
Jarosław Żeliński – analityk biznesowy
Prezentacja prowadzonej działalności,
sposobu prowadzenia procesu analizy i
projektowania oraz zasad współpracy

… listy … listy …
• Szanowny Panie, […] Jestem specjalistą w
zakresie HR i poszukuję wspólnego języka z
programistami tworzącymi czasami dla mnie
oprogramowanie. Potwierdzam Pana zdanie -
metody opisowe i zorientowane na przypadki
nie są skuteczne a nawet powiem
bezużyteczne gdyż programiści nie czytają ich
do końca. Proszę o pomoc i z góry dziękuję.

… listy … listy …
• Jestem pod wielkim wrażeniem Pana artykułów,
tym bardziej, że na przykładzie własnej firmy
miałem okazję doświadczyć problemów
wdrożeniowych, których przyczyny i skutki Pan
opisuje. Niestety mimo najwyższej staranności i
zaangażowania z naszej strony jeden z
GoldPartnerów i jednocześnie laureat nagrody
partnera roku firmy Microsoft zdołał "modelowo
położyć na łopatki" nasz projekt. W związku z tym
pewnie będę miał przyjemność popracować z
Panem. Jak się domyślam, prawdopodobnie w
ten właśnie sposób trafia do Pana większość
klientów.

O mnie…
© Jarosław Żeliński IT-Consulting 4
Od 1991 roku w branży IT i zarządzania
Od 1998 roku jako niezależny analityk, projektant i
firma IT-Consulting.pl
Dziesiątki publikacji w prasie branżowej i
gospodarczej
Wykładowca: 2005-20012 Akademii Morskiej i
Politechniki Warszawskiej, od 2014 wykładowca
Wyższej Szkoły Zarządzania i Technik Informatycznych
pod auspicjami PAN od 2014
Kilkudziesięciu odbiorców usług doradczych, małe,
średnie i duże firmy zarówno informatyczne jak i ich
klienci oraz administracja publiczna.
Poświadczenie bezpieczeństwa wydane przez ABW
Publikacje między innymi w …

A na grzyba nam Pan Analityk? Przecież analizę
zrobimy sami, a jak nie - to zrobi to dostawca.
Perspektywa obserwatora z ziemi
(system geocentryczny)
Odkryta Prawda (system
heliocentryczny)

Samodzielny ekspert a korporacja
konsultingowa
– Zespoły realizują monumentalne realizacje jednak są to dzieła pojedynczych ludzi, zarówno Mona Lisa
jak i freski w Kaplicy Sykstyńskiej powstały w głowie jednego człowieka.
– Strategiczne idee tworzone są przez pojedynczych ludzi, do wdrożenia ich może być wymagany sprawny
zespół.
– Wspólnie z moimi klientami Tworzę ich strategie i rozwiązania, które potem wdrażają zespoły
dostawców tych rozwiązań ….
• Nie mam ograniczeń korporacyjnych na swoje pomysły, idee i rekomendacje, nie wiąże mnie
żadna polityka korporacyjna, kierunki myślenia wyznacza mi tylko klient i jego sytuacja.
• Nie jestem związany umowami prowizyjnymi i lojalnościowymi z żadnym dostawcą
oprogramowania.
• Pracuję zawsze sam, pozwalają mi na to narzędzia wspierające obieg dokumentów oraz
narzędzia wspomagające analizę i projektowanie CASE. Zwalniają mnie one z ogromu
żmudnej pracochłonności a Państwa z ponoszenia jej kosztów.
6
2016-09-29

Audyt i Analiza Biznesowa organizacji
Specyfikacje zorientowane na modele

Trzy poziomy analizy i opisu organizacji – elementy
audytu
Źr. http://www.bptrendsassociates.com/
Strategia rynkowa, cele
biznesowe
Procesy biznesowe, struktura
organizacyjna, reguły biznesowe. To
sposób w jaki firma realizuje cele
biznesowe
Procedury i instrukcje, zasoby. Jak
realizowane są poszczególne zadania
Celem prowadzenia audytu jest zrozumienie i
udokumentowanie know-how organizacji: opracowanie modelu
mechanizmu i zasad jej działania. Korzyścią z posiadania takiej
dokumentacji jest możliwość bezpiecznej oceny i analizy
wpływu rekomendowanych zmian oraz ochrona prawna.

Struktura organizacyjna
Bardzo ważny model z perspektywy analizy ról w procesach
biznesowych. Wymaga formalizacji w toku analizy i
projektowania

Struktura (model) motywacji biznesowej i strategii
Każda organizacja powinna mieć
jasno określone cele i ich
mierniki. Nowe rozwiązania mają
im służyć i niczemu innemu.

Proces biznesowy: łańcuchy aktywności i ich cele
Modele procesów biznesowych
to nie są detalicznie opisane
czynności. To łańcuchy
aktywności tworzące produkty
biznesowe. Pozwalają
zidentyfikować przepływ
informacji, reguły biznesowe oraz
wychwycić miejsca potencjalnej
optymalizacji i naprawy.

Procedury realizacji wybranych aktywności w
procesach
• W postaci listy:
1. K jg kdjh dfk
1. Dk; fhkjdhgkldfj g
2. Sdkj gkjdfh lfkd
2. Kdjh kjldfs g
3. Sdk ghkjdf g
• W postaci diagramów i schematów blokowych
Detale wybranych aktywności w
procesach są dokumentowane
niezależnie lub wykorzystywane
są dokumenty (np. procedury)
istniejące w firmie.

Zestawienia
• Zestawienie:
Słownik pojęć
biznesowych
• Zestawienie:
Lista reguł
biznesowych
• Zestawienie:
Wymagania
biznesowe
Tych elementów nie „rysujemy”
na schematach blokowych,
powołujemy się na nie. W
przeciwnym wypadku schematy
te stają się bardzo złożone i
nieczytelne. W tej postaci
dołączane są także jako
wymagania na oprogramowanie.

Grupy referencyjnych procesów jako szkielet
analizy i audytu
Taki ogólny schemat, mapa
podstawowych procesów,
stanowi początek projektu, jego
celem jest określenia zakresu
projektu.

Rola zamawiającego
• Określenie celu i zakresu projektu
– Jak brzmi kluczowe pytanie, na które szukamy odpowiedzi?
– Kluczowe problemy jakie należy rozwiązać.
– Oczekiwane efekty.
• Wyznaczenie ekspertów recenzentów, ich rola:
– Dostarczanie danych i informacji
– Recenzowanie powstających elementów dokumentacji
• Komunikacja:
– Standardowo elektroniczny, interaktywny, rejestrowany
obieg dokumentów (platforma dostarczana przez
Wykonawcę)
– Spotkania w ustalonych odstępach czasu (raz, dwa razy w
miesiącu)

Iteracyjny proces analizy
Analiza
dokumentacji
Modele
(hipoteza) Konsultacje z
ekspertami
Korekta
modeli
Uwagi do
modeli
Modele
Cel projektu Analiza celu
biznesowego
Raport z
analizy
Brak uwag
Opracowanie własne, Jarosław Żeliński
Określenie
zakresu dalszych
działań

Konsultacje i internetowy przepływ informacji
analityk
Ekspert
dziedzinowy
Ekspert
dziedzinowy
Schemat blokowy -
model
Panel dyskusyjny
pomiędzy analitykiem
i ekspertami

Struktura produktów projektu
(c) Jarosław Żeliński http://IT-Consulting.pl 18

Model jako uniwersalne narzędzie
• Opracowany w toku analizy
model biznesowy może posłużyć
jako uniwersalne narzędzie do
innych analiz i projektów…
Model procesów
Modelowanie
i optymalizacja
Specyfikacja
kosztów działań
Specyfikacja
procesów i
kluczowych
mierników jakości
Specyfikacja
wymagań na
oprogramowanie
Struktura
organizacyjna
zasobów ludzkich

DOKUMENTACJA WYMAGAŃ JAKO
PROJEKT LOGIKI DZIAŁANIA
Po opracowaniu raportu z analizy powstaje Specyfikacja wymagań.
Jest to dokumentacja techniczna dla dostawcy oprogramowania. W tej
postaci jest mniej ryzykowna niż przekazanie opisu i listy oczekiwań… Ta część
dokumentacji jest adresowana dla developera: dostawcy rozwiązania.

Trudność z określaniem wymagań stawianych
systemowi
• Problemy, w których rozwiązaniu mają pomóc
budowane złożone systemy są zwykle „problemami
złośliwymi” (Rittel i Webber, 1973). „Problem
złośliwy” to taki skomplikowany problem, w którym
jest tak wiele powiązanych ze sobą bytów, że nie
istnieje jego ostateczna specyfikacja.
• Prawdziwy charakter problemu objawia się
dopiero w miarę opracowywania rozwiązania.

Aplikacja i to czego od niej oczekujemy
W toku projektowania rozwiązania
powstaje jego architektura. Każda
wymagana aplikacja jest dokumentowana w
sposób zrozumiały dla Zamawiającego jako
lista wymaganych usług (np. system na
pozwalać na tworzenia faktur i zarządzanie
nimi)

Każda Usługa aplikacji ma swój scenariusz
Każda usługa aplikacji ma dedykowany opis
(scenariusz) pozwalający na jej zrozumienie
i przetestowanie czy całość jest spójna. Dla
Dostawcy jest to test poprawności.

Logika biznesowa wymaga opisania jej jednoznacznie
metodami zrozumiałymi dla developera
Wewnętrzna struktura każdej aplikacji ma
opis jej struktury logicznej pozwalający na
upewnienie się, że znane są zasoby
wymagane, by każdy scenariusz usługi był
możliwy do wykonania.

Detale…
• Detale opisujące to co ma realizować
dostarczane oprogramowanie zawarte jest we
wzorach dokumentów, słownikach pojęć,
regułach biznesowych.
• Nie ma znaczenia to czy dostarczane
oprogramowanie jest gotowe czy wykonywane
jako dedykowane: pierwsze jest albo nie jest
zgodne z wymaganiami (i dokonujemy
wyboru) a drugie musi je spełniać…

… forum programistów …
• No naprawdę świetny dokument. Zajrzałem do
tego pdf-a i muszę powiedzieć że treść i forma
super, gratuluję. Gdyby każdy projekt w IT był
robiony na podstawie takiej specyfikacji to
może inaczej wyglądałyby proporcje projektów
zakończonych do porzuconych.

WYBÓR DOSTAWCY I REALIZACJA
Po opracowaniu raportu z analizy powstaje Specyfikacja wymagań.
Kolejny etap to…

Analiza, projektowanie i wdrożenie rozwiązania
W toku projektu jako Audytor bardzo
dobrze poznaję organizację, później jako
projektant doskonale rozumiem co i
dlaczego jest wymagane. Rozumiejąc i
znając specyfikę pracy Dostawcy, mogę
merytorycznie nadzorować realizację w
imieniu Zamawiającego.

Wybór dostawcy i wdrożenie
• Wybór dostawcy, zależnie od wymogów prawnych i
sytuacji, ustalany jest indywidualnie.
• Od momentu wyboru dostawcy Analityk pełni rolę
nadzoru autorskiego, w metodykach zwinnych (np.
SCRUM) określaną jako Product Owner (lub Client
Proxy).

PODSUMOWANIE…

Jako firma:
• Od roku 1998 pracuję jako niezależny ekspert, firma doradczo-
konsultingowa.
• Jako realizator usługi zapewniam na czas realizacji projektu:
– Opisaną metodykę realizacji projektów analitycznych, wraz z
niezbędnymi prawami autorskimi do niej, w tym plan komunikacji,
którą przedstawiam w ofercie i załączam do umowy.
– Metodykę zarządzania projektem.
– Oprogramowanie wspomagające elektroniczny, bezpieczny przepływ
informacji i dokumentów pomiędzy ekspertami dziedzinowymi
zamawiającego a Doradcą w celu bieżącego opiniowania produktów
analizy.
– Oprogramowanie wspomagające zarządzania zadaniami w projekcie.
– Narzędzia CASE (Computer Aided System Engineering), w pełni zgodne
ze standardowymi systemami notacyjnymi, źródłowe pliki projektowe
tak powstałe są przekazywane wraz produktami umowy.
• Wszystkie dokumenty powstają w języku polskim (dopuszcza się
słownictwo dziedzinowe IT w języku angielskim).

Jako ekspert:
• Bardzo dobrze znam zagadnienia z obszaru zarządzania i marketingu na poziomie
pozwalającym sprawnie korzystać z takich dokumentów jak plany marketingowe,
strategie przedsiębiorstwa, zarządzanie produktami oraz brać aktywny udział w
ustalaniu treści takich dokumentów.
• Posiadam ponad 15 letnie doświadczenie w dużych firmach na stanowiskach
związanych z marketingiem i strategią rynkową.
• Sprawnie posługuję się systemami pojęciowymi i notacjami: Business Motivation
Model (http://www.omg.org/spec/BMM/), Business Process Modeling Notation
(http://www.omg.org/bpmn/), Unified Modeling Language
(http://www.uml.org/), Case Management Modeling and Notation
(http://www.omg.org/spec/CMMN/).
• Znam i stosuję w praktyce zagadnienia z zakresu architektury korporacyjnej i SOA
(Service Oriented Architekture), w szczególności architekturę, komponentową,
zorientowaną na usługi.
• Znam i stosuje w praktyce obiektowe metody analizy i projektowania, wzorce
architektoniczne i projektowe (w szczególności MVC/MVVM, wzorce Domain
Driven Design i BCE).
• Znam i sprawnie posługuję się metodami zarządzania projektami opartymi na
planowaniu i dokumentowaniu zakresu, terminów i kosztów prac.

Doświadczenie…
• Mam doświadczenie od 1991 roku w projektach IT, oraz w:
– Bezpośredniej współpracy z zarządami firm, także dużych spółek
giełdowych
– W opisywaniu tego jak firmy działają, w ochronie know-how firm
(prawo autorskie i prawo o zwalczaniu nieuczciwej konkurencji)
– W analizach i projektowaniu systemów informatycznych nawet dla
bardzo dużych firm i małych też
– W nadzorowaniu prac dostawców oprogramowania
• Od 2004 roku, bez przerwy, funkcjonuję na rynku samodzielnie jako
niezależny ekspert : analityk i projektant systemów.
• Jestem stale zapraszany na seminaria i konferencje w roli prelegenta
• OD 2005 Wykładowca akademicki. Od roku 2014 na zaproszenie
władz uczelni, prowadzę wykłady na Wyższej Szkole Zarządzania i
Technik Informacyjnych pod auspicjami Polskiej Akademii Nauk.

…wymagania na nowe rozwiązania muszą być oparte na faktach i
realnych scenariuszach. Więc ile warte są wizje w projektach agile albo
wydumane w toku warsztatowych burz mózgów litanie życzeń i
pomysłów przyszłych użytkowników? Nie tylko moim zdaniem: nie są
wiele warte i nie powinny być wymaganiami.

CZY MAMY CZAS I OCHOTĘ NA
PREZENTACJE PRAKTYCZNĄ?
Jeśli tak, to zapraszam … na dalszą prezentację lub spotkanie

Metoda analizy i specyfikowania wymagań na oprogramowanie

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Metoda analizy i specyfikowania wymagań na oprogramowanie

Similaire à Metoda analizy i specyfikowania wymagań na oprogramowanie (20)

Metoda analizy i specyfikowania wymagań na oprogramowanie