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

(c) Jarosław Żeliński 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 akcyjnychOd 2004 roku jako niezależny ekspert i analitykDziesiątki publikacji w prasie branżowej IT i gospodarczejCzłonek stowarzyszenia doradców gospodarczych Były wykładowca katedry systemów informacyjnych wydziału przedsiębiorczości Akademii Morskiej w GdyniKilkudziesię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 ABWByły ekspert analityk biznesowy przy gabinecie komisji nadzoru finansowegoWykł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 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 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 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 6

Analiza organizacji – model nadrzędny systemu

2015-05-07

(c) Jarosław Żeliński 7

System IT jako wewnętrzny „podsystem” organizacji

2015-05-07

(c) Jarosław Żeliński 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 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 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 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 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 13

Struktura jako podział pracy

• Komponentowy model systemu• Granice podsystemów jako zakresy podprojektów• …

2015-05-07

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

(c) Jarosław Żeliński 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 16

Paradygmat obiektowy – jako odpowiedź na trudne pytania

• Symulacyjne podejście do architektury• …

2015-05-07

(c) Jarosław Żeliński 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 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 19

PYTANIA…?

Dziękuję za uwagę…

Jarosław Żeliński – Analityk Biznesowyj.zelinski@it-consulting.plhttp://IT-Consulting.plGSM: 0-608 05 90 20

W sprawach referatu kontakt:konsultacje@it-consulting.pl

2015-05-07