Successfully reported this slideshow.

Klasyfikacja wymagań jako sposób zarządzania nimi

1

Share

1 of 19
1 of 19

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Klasyfikacja wymagań jako sposób zarządzania nimi

  1. 1. Klasyfikacja wymagań jako sposób zarządzania nimi. Systemowa analiza organizacji jako metoda specyfikowania wymagań Jarosław Żeliński – analityk biznesowy, projektant systemów 2014-03-18 Konferencja Inżynieria Wymagań
  2. 2. Agenda • Co wiemy o wymaganiach • Analiza i projektowanie obiektowe – Programowanie obiektowe to nie to samo co analiza i projektowanie… • Klasyfikacja wymagań • Lesson learned czyli co na to praktyka… 2014-03-18 (c) Jarosław Żeliński 2
  3. 3. IEEE 830-1998 • Poprawna: nie może być np. niezgodna z prawem • Jednoznaczna: (log. «stosunek zachodzący między co najmniej dwoma różnymi wyrażeniami, z których każde ma to samo znaczenie» • Kompletna: o tym za moment • Spójna: brak konfliktów logicznych ale o tym także za moment • Uporządkowana wg ważności/stabilności: np. metodą triage czyli każde wymaganie ma jeden z trzech atrybutów – musi być, powinno być, mogło by być (inna wersja to waga wymagania dla całego projektu: duża średnia, mała) • Weryfikowalna: można jednoznacznie stwierdzić, że wymaganie zostało zrealizowane • Modyfikowalna: to dotyczy struktury dokumentu i narzędzia jakim powstał dokument wymagań • Umożliwiająca śledzenie powiązań: dotyczy struktury dokumentu jak i jego formatu (dokumentacja html będzie lepsza od dokumentacji tekstowej do przeglądania ale nie do druku). 2014-03-18 (c) Jarosław Żeliński 3
  4. 4. Taka sytuacja… 2014-03-18 (c) Jarosław Żeliński 4
  5. 5. SYSTEMOWA ANALIZA ORGANIZACJI JAKO METODA SPECYFIKOWANIA WYMAGAŃ 2014-03-18 (c) Jarosław Żeliński 5
  6. 6. MDA i OOAD Model Driven Architecture to trzyetapowy proces tworzenia oprogramowania. OOAD/ DDD Zamawiający Developer Model jako wymaganie dziedzinowe Architektura biznesowa 2014-03-18 (c) Jarosław Żeliński 6
  7. 7. The current state of CIM creation in the OOA Źr. Formal Computation Independent Model of the Problem Domain within the MDA Janis Osis1, Erika Asnina1, Andrejs Grave11 Faculty of Computer Science and Information Technology, Institute of Applied Computer Systems, Riga Technical University, Latvia {janis.osis, erika.asnina}@cs.rtu.lv, andrejs.grave@inbox.lv 2014-03-18 (c) Jarosław Żeliński 7
  8. 8. (źr.) OMG.org MDA® Specifications Applications and Frameworks (that is, parts of applications that perform a particular function) can all be defined in the MDA as a base PIM that maps to one or more PSMs and implementations. Standards written this way enjoy two advantages: • The base PIM is truly a business specification, defining business functionality and behavior in a technology-independent way. Technological considerations do not intrude at this stage, making it easy for business experts to model exactly the business rules they want into the PIM. • Once business experts have completed the PIM, it can be implemented on virtually any platform, or on multiple platforms with interoperability among them, in order to meet the needs of the industry and companies that use it. 2014-03-18 (c) Jarosław Żeliński 8
  9. 9. Architektura Korporacyjna i SOA Misja i Wizja firmy Proces (aktywność) Proces (aktywność) Proces (aktywność) Proces (aktywność) Przypadki Użycia Usługi Aplikacyjne integracja DXBM BO BO Środowisko Środowisko SOA Architektura Korporacyjna BO BO BO BO 2014-03-18 (c) Jarosław Żeliński 9
  10. 10. KLASYFIKACJA WYMAGAŃ JAKO SPOSÓB ZARZĄDZANIA NIMI. 2014-03-18 (c) Jarosław Żeliński 10
  11. 11. Model pojęciowy wymaganie «warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać» usługa «pomoc okazana komuś» przypadek «pojedyncze zdarzenie lub pojedyncza sytuacja» użycie «stosowanie czegoś» dziedzina «zakres czyjegoś działania w obrębie nauki, gospodarki, techniki, kultury itp.» aplikacja «komputerowy program użytkowy» (źr. słownik języka polskiego PWN) 2014-03-18 (c) Jarosław Żeliński 11
  12. 12. Analiza biznesowa i specyfikowanie wymagań Model CIM (notacja BPMN, SBVR, BMM) Model PIM (notacja UML) Model procesów biznesowych Kontekst projektu (notacja UML) Model PIM (notacja UML) Model przypadków użycia Model dziedziny Model Sekwencji Obiekty biznesowe Reguły biznesowe Scenariusze obiekty operacje Wymagania dziedzinowe Wymagania funkcjonalne Wymagania poza-funkcjonlane Przypadki użycia jako usługi systemu czyli usługi aplikacyjne Wszelkie ograniczenia i wymagane osiągi 2014-03-18 (c) Jarosław Żeliński 12
  13. 13. Po co to wszystko? • Bo: – skoro kluczowym problemem w projektach z obszaru inżynierii oprogramowania są wadliwe specyfikacje wymagań – a opis „czarnej skrzynki” jest z zasady niejednoznaczny • więc bezpieczniej jest przekazać wymagania w postaci projektu a nie tylko listy wymaganych cech bo tak opracowane wymagania są: – Spójne – Kompletne – Niesprzeczne Co można sprawdzić poprzez śladowanie… 2014-03-18 (c) Jarosław Żeliński 13
  14. 14. Martin Fowler: • Wyobraźmy sobie kogoś, kto chce napisać program symulujący grę w snookera. Problem ten może zostać opisany przypadkami użycia opisującymi powierzchownie cechę: "Gracz uderza biała kulę, która przemieszcza się z pewną prędkością, ta po określonym czasie uderza czerwoną kulę pod określonym kątem, uderzona czerwona kula przemieszcza się na pewna odległość w pewnym kierunku." • Możesz sfilmować setki tysięcy takich uderzeń, zarejestrować parametry każdego uderzenia i jego skutki. Jednak tą metodą i tak nie stworzysz nawet dość dobrej symulacji. Aby napisać na prawdę dobrą grę, powinieneś raczej zrozumieć prawa rządzące ruchem kul, ich zależność od siły i kierunku uderzenia, kierunku itp. Zrozumienie tych praw pozwoli Ci znacznie łatwiej napisać dobre oprogramowanie. 2014-03-18 (c) Jarosław Żeliński 14
  15. 15. Czego i skąd wymagać… 2014-03-18 (c) Jarosław Żeliński 15
  16. 16. Podział ról • OOA i OOD jest łączone w OOAD z tego powodu, że obiektowy opis (model) "czegoś" jest 9w metodach obiektowych) zarazem projektem "tego czegoś". Mając obiektowy model oprogramowania (części opisującej jego biznesową logikę działania, nazywanej Modelem Dziedziny) możemy sprawdzić (przetestować) jak spełnia on wymagania funkcjonalne zanim jeszcze, powstanie znacznie droższa od projektu, implementacja. Mamy szanse, relatywnie niskim kosztem, zmienić projekt zanim uruchomimy kosztowny zespół programistów. Na bazie takiego modelu możliwe jest w ogóle wykonanie analizy wykonalności. • Metoda ta jest sprawdzona, działa, jest skuteczna. Pierwszy, głośno, napisał o tym Eric Evans w dziele Domain-Driven Design: Tackling Complexity in the Heart of Software . Problem polega na tym, że biznesowa analiza obiektowa (OOAD), dająca jako efekt model dziedziny (czyli sedno biznesowych aplikacji), wymaga zupełnie innych kompetencji (nie licząc rozumienia samej obiektowości) niż kompetencje programistów i architektów oprogramowania. Nie prawdą jest, że tylko "developer" ma tu kompetencje do projektowania oprogramowania. W obszarze analizy i modelowania "biznesu" z reguły nie ma żadnych kompetencji. • Potwierdza to także obecny model kompetencji Analityka Biznesowego prezentowany przez organizację IIBA. 2014-03-18 (c) Jarosław Żeliński 16
  17. 17. Lesson learned czyli co na to praktyka… Metody MDA/OOAD 50% 50% 20% 80% Harmonogram Koszt Opracowanie CIM i PIM Implementacja 2014-03-18 (c) Jarosław Żeliński 17
  18. 18. 80% wpadek i od lat ani drgnie … • Jako zwierzęta, ludzie są w przytłaczającej większości konformistami szukającymi prostych sposobów na przeżycie. Heurystyka, jako metoda podejmowania decyzji, góruje nad analitycznym myśleniem, nie dopuszczamy myśli, że coś, co komukolwiek się udało, może być trudne, dajemy wiarę temu, że ukryto przed nami ten „prosty sposób”. Praktyka jest straszna : otóż nie istnieją proste sposoby rozwiązywania złożonych problemów (nie licząc odkryć przypadkowych). • Daniel Kahneman w książce „Thinking, fast and slow“ pokazuje, że nasze poglądy i postępowanie kształtują dwa systemy myślowe: szybki (automatyczny, bezrefleksyjny) i wolny (oparty na refleksji i namyśle). Zastanawiające, jak często ludzie korzystają tylko z tego pierwszego systemu. 2014-03-18 (c) Jarosław Żeliński 18
  19. 19. O mnie… 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 Członek stowarzyszenia doradców gospodarczych 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 przy gabinecie komisji nadzoru finansowego Projekty analityczne między innymi dla… Publikacje między innymi w … 2014-03-18 (c) Jarosław Żeliński 19

×