Inżynieria systemów to także analiza i precyzowanie wymagań, to zawieranie kontraktu na wykonanie i dostarczenie produktu. Oprogramowanie, mimo wymaganej i popularnej "zwinności" także należy tworzyć "z głową".....

1. Jak budować zakres projektu z pomocą inżynierii
systemowej by niwelować ryzyko złego określenia
wymagań i zakresu projektu
Jarosław Żeliński – analityk biznesowy,
projektant systemów
Konferencja Project Engeneering 2015

2. O mnie…
Od 1991 roku w branży IT i zarządzania jako analityk
projektant rozwiązań
Od 1998 – 2004 doradca w kilku spółkach akcyjnych
Od 2004 roku jako niezależny ekspert i analityk
Dziesiątki publikacji w prasie branżowej IT i gospodarczej
Członek stowarzyszenia doradców gospodarczych
 Były wykładowca katedry systemów informacyjnych
wydziału przedsiębiorczości Akademii Morskiej w Gdyni
Kilkudziesięciu odbiorców usług doradczych, małe,
średnie i duże firmy zarówno informatyczne jak i ich
klienci.
Poświadczenie bezpieczeństwa wydane przez ABW
Były ekspert analityk biznesowy przy gabinecie komisji
nadzoru finansowego
Wykładowca Wyższej Szkoły Informatyki Stosowanej i
Zarządzania pod auspicjami Polskiej Akademii Nauk
Projekty analityczne
między innymi dla…
Publikacje między innymi w …
2015-05-07 (c) Jarosław Żeliński 2

3. Agenda
• Analiza systemowa
• Model organizacji
• Model systemu
• Wykorzystywane notacje
• Zarządzanie zakresem projektu
• Wymagania jako kontrakt
• Nieco o inżynierii oprogramowania -
projektowanie
2015-05-07 (c) Jarosław Żeliński 3

4. Projekt analityczny jako opracowanie planu
• Projekty inżynierskie, IT w
szczególności, powinny być
planowane bo ich przedmiotem
są konstrukcje
• Planem tego co ma powstać jest
projekt tej konstrukcji
• Nie jest powiedziane, że od razu
musi powstać jej detaliczny
projekt
• Jednak projekt, co najmniej jego
szkielet, to osnowa całości, wizja
tego co powstanie, do czego to
posłuży i jak będzie wyglądało.
2015-05-07 (c) Jarosław Żeliński 4

5. Analiza systemowa – czym jest
• Analiza systemowa - (metoda systemowa) zbiór metod i technik
analitycznych, ocenowych i decyzyjnych służących racjonalnemu
rozwiązywaniu systemowych sytuacji decyzyjnych; jest badaniem
wspomagającym działania osób odpowiedzialnych za decyzje lub linie
postępowania w warunkach niepewności i ryzyka; ma na celu określenie
pożądanego postępowania przez rozpoznanie i rozważenie dostępnych
wariantów oraz porównanie przewidywanych ich bliższych i dalszych
następstw; podstawowe pytania w analizie systemowej to: jak jest i
dlaczego jest tak jak jest oraz jak powinno być i co należy uczynić, aby
było tak jak być powinno. (Sienkiewicz, 1994)
2015-05-07 (c) Jarosław Żeliński 5

6. Analiza organizacji – model nadrzędny systemu
2015-05-07 (c) Jarosław Żeliński 6

7. System IT jako wewnętrzny „podsystem”
organizacji
2015-05-07 (c) Jarosław Żeliński 7

8. Notacje jako formalne metody opisu -
modelowanie
• Notacja - zestaw zdefiniowanych symboli i ich wzajemnych
związków, symbole notacji mają ściśle określone znaczenia
zwane semantyką notacji, dopuszczalne związki między
symbolami tworzą syntaktykę notacji, notacja stanowi sobą
określoną przestrzeń pojęciową (opr. wł. J.Żeliński na podst.
literatury)
• Metody formalne (ang. formal methods) - w informatyce
tym terminem określa się oparte na matematyce podejścia
do specyfikacji, projektowania i weryfikacji
oprogramowania lub systemów informatycznych.
• Użycie notacji i języków ze zdefiniowanym matematycznym
znaczeniem pozwala precyzyjnie określić, co system
informatyczny powinien robić, jakie mają być jego
właściwości oraz zweryfikować poprawność działania
systemu. (WIKI)
2015-05-07 (c) Jarosław Żeliński 8

9. BPMN – notacja specyficzna dla biznesu
• Business Process Model and Notation, system
pojęciowy i graficzna notacja pozwalająca
modelować i dokumentować w graficznej
formie procesy biznesowe i procedury;
pozwala także na modelowanie i
dokumentowanie współpracy miedzy
organizacjami.
• Notacja oparta na „biznesowym” systemie
pojęciowym, adresowana do „biznesu”
2015-05-07 (c) Jarosław Żeliński 9

10. UML i SysML jako notacje specyficzne dla inżynierii
• Unified Modeling Language, notacja (system pojęciowy)
opublikowany przez organizację Object Management Group,
model pojęciowy dla analityków i architektów systemów,
twórców oprogramowania a także innych, w tym
biznesowych, zorientowanych na obiektowy paradygmat
analizy i projektowania.
• SysML, czyli System Modeling Language, to rozszerzenie języka
UML, który stanowił do tej pory swego rodzaju standard w
inżynierii oprogramowania. SysML został dostosowany do
specyficznych potrzeb inżynierów systemowych, zajmujących
się projektami w sposób całościowy. Pozwala na specyfikację,
analizę, projektowanie i weryfikację złożonych systemów
różnego rodzaju.
2015-05-07 (c) Jarosław Żeliński 10

11. Projekt wymaga WBS czyli Work Breakdown
Structure
• Model całości
• Dekompozycja na „atomowe” zadania do
wykonania, możliwe do przydzielenia jednej
osobie lub zespołowi.
2015-05-07 (c) Jarosław Żeliński 11

12. Mamy WBS i co dalej?
• Niepodzielne komponenty
• Kto powinien je tworzyć?
• Czy można podzielić projekt na podprojekty i jak to zrobić?
2015-05-07 (c) Jarosław Żeliński 12

13. Struktura jako podział pracy
• Komponentowy model systemu
• Granice podsystemów jako zakresy podprojektów
• …
2015-05-07 (c) Jarosław Żeliński 13

14. Stwierdzenie, że wykonano nie jest proste
• Czym są wymagania
• Czy wymagania mogą
być testami
• Co to znaczy, że
dostarczono
zamówiony produkt
• wymaganie «warunek
lub zespół warunków,
którym ktoś lub coś
musi odpowiadać»
(SJP PWN)
2015-05-07 (c) Jarosław Żeliński 14

15. Metody obiektowe analizy i projektowania jako
odpowiedź na potrzebę zarządzania zmiennym
zakresem
• Zmienność
zakresu
projektu, skąd
się bierze?
• Czy zmienność
zakresu projektu
niszczy projekt?
• Jak radzić sobie
ze zmiennością
zakresu projektu
(wymagań)
• …
2015-05-07 (c) Jarosław Żeliński 15

16. Paradygmat obiektowy – jako odpowiedź na
trudne pytania
• Symulacyjne podejście do architektury
• …
2015-05-07 (c) Jarosław Żeliński 16

17. Architektura oprogramowania jako metoda pracy
• Wzorce architektoniczne
– MVC (Model View Controller)
– BCE (Boundary Controll Entity, dawniej w RUP
Robustness Diagram)
– DDD (Domain Driven Design)
• Frameworki – już nie piszemy
oprogramowania „od zera”…
2015-05-07 (c) Jarosław Żeliński 17

18. Na koniec; czarna skrzynka czyli przypadki użycia
• Use Case (przypadek użycia systemu)
• UC jako kontekst
• UC jako kontrakt
• UC jako wymagania
2015-05-07 (c) Jarosław Żeliński 18

19. PYTANIA…?
Dziękuję za uwagę…
(c) Jarosław Żeliński 192015-05-07