Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Metoda analizy i specyfikowania wymagań na oprogramowanie

2,663 views

Published on

Jarosław Żeliński IT-Consulting
Analizy systemowe i projektowanie

Published in: Business
  • Be the first to comment

Metoda analizy i specyfikowania wymagań na oprogramowanie

  1. 1. 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
  2. 2. … 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ę.
  3. 3. … 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.
  4. 4. 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 …
  5. 5. 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) © Jarosław Żeliński IT-Consulting 5
  6. 6. 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
  7. 7. Audyt i Analiza Biznesowa organizacji Specyfikacje zorientowane na modele
  8. 8. Trzy poziomy analizy i opisu organizacji – elementy audytu © Jarosław Żeliński IT-Consulting 8 Ź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.
  9. 9. Struktura organizacyjna © Jarosław Żeliński IT-Consulting 9 Bardzo ważny model z perspektywy analizy ról w procesach biznesowych. Wymaga formalizacji w toku analizy i projektowania
  10. 10. Struktura (model) motywacji biznesowej i strategii © Jarosław Żeliński IT-Consulting 10 Każda organizacja powinna mieć jasno określone cele i ich mierniki. Nowe rozwiązania mają im służyć i niczemu innemu.
  11. 11. Proces biznesowy: łańcuchy aktywności i ich cele © Jarosław Żeliński IT-Consulting 11 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.
  12. 12. 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 © Jarosław Żeliński IT-Consulting 12 Detale wybranych aktywności w procesach są dokumentowane niezależnie lub wykorzystywane są dokumenty (np. procedury) istniejące w firmie.
  13. 13. Zestawienia • Zestawienie: Słownik pojęć biznesowych • Zestawienie: Lista reguł biznesowych • Zestawienie: Wymagania biznesowe © Jarosław Żeliński IT-Consulting 13 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.
  14. 14. Grupy referencyjnych procesów jako szkielet analizy i audytu © Jarosław Żeliński IT-Consulting 14 Taki ogólny schemat, mapa podstawowych procesów, stanowi początek projektu, jego celem jest określenia zakresu projektu.
  15. 15. 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) © Jarosław Żeliński IT-Consulting 15
  16. 16. Iteracyjny proces analizy © Jarosław Żeliński IT-Consulting 16 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ń
  17. 17. Konsultacje i internetowy przepływ informacji © Jarosław Żeliński IT-Consulting 17 analityk Ekspert dziedzinowy Ekspert dziedzinowy Schemat blokowy - model Panel dyskusyjny pomiędzy analitykiem i ekspertami
  18. 18. Struktura produktów projektu (c) Jarosław Żeliński http://IT-Consulting.pl 18
  19. 19. 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… © Jarosław Żeliński IT-Consulting 19 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
  20. 20. 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. © Jarosław Żeliński IT-Consulting 20
  21. 21. 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.
  22. 22. Aplikacja i to czego od niej oczekujemy © Jarosław Żeliński IT-Consulting 22 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)
  23. 23. Każda Usługa aplikacji ma swój scenariusz © Jarosław Żeliński IT-Consulting 23 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.
  24. 24. Logika biznesowa wymaga opisania jej jednoznacznie metodami zrozumiałymi dla developera © Jarosław Żeliński IT-Consulting 24 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.
  25. 25. 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ć… © Jarosław Żeliński IT-Consulting 25
  26. 26. … 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.
  27. 27. WYBÓR DOSTAWCY I REALIZACJA Po opracowaniu raportu z analizy powstaje Specyfikacja wymagań. Kolejny etap to… © Jarosław Żeliński IT-Consulting 27
  28. 28. Analiza, projektowanie i wdrożenie rozwiązania © Jarosław Żeliński IT-Consulting 28 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.
  29. 29. 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). © Jarosław Żeliński IT-Consulting 29
  30. 30. PODSUMOWANIE… © Jarosław Żeliński IT-Consulting 30
  31. 31. 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). © Jarosław Żeliński IT-Consulting 31
  32. 32. 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. © Jarosław Żeliński IT-Consulting 32
  33. 33. 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. © Jarosław Żeliński IT-Consulting 33
  34. 34. …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. © Jarosław Żeliński IT-Consulting 34
  35. 35. CZY MAMY CZAS I OCHOTĘ NA PREZENTACJE PRAKTYCZNĄ? Jeśli tak, to zapraszam … na dalszą prezentację lub spotkanie © Jarosław Żeliński IT-Consulting 35

×