Jak budować zakres projektu z pomocą inżynierii systemowej
-
Upload
jaroslaw-zelinski -
Category
Technology
-
view
578 -
download
1
Transcript of Jak budować zakres projektu z pomocą inżynierii systemowej
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 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 [email protected]://IT-Consulting.plGSM: 0-608 05 90 20
W sprawach referatu kontakt:[email protected]
2015-05-07