Successfully reported this slideshow.

Jak budować zakres projektu z pomocą inżynierii systemowej

0

Share

Loading in …3
×
1 of 19
1 of 19

Jak budować zakres projektu z pomocą inżynierii systemowej

0

Share

Download to read offline

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ą".....

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ą".....

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Jak budować zakres projektu z pomocą inżynierii systemowej

  1. 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. 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. 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. 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. 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. 6. Analiza organizacji – model nadrzędny systemu 2015-05-07 (c) Jarosław Żeliński 6
  7. 7. System IT jako wewnętrzny „podsystem” organizacji 2015-05-07 (c) Jarosław Żeliński 7
  8. 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. 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. 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. 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. 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. 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. 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. 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. 16. Paradygmat obiektowy – jako odpowiedź na trudne pytania • Symulacyjne podejście do architektury • … 2015-05-07 (c) Jarosław Żeliński 16
  17. 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. 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. 19. PYTANIA…? Dziękuję za uwagę… (c) Jarosław Żeliński 192015-05-07

×