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ń

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

Taka sytuacja…

2014-03-18

(c) Jarosław Żeliński 5

SYSTEMOWA ANALIZA ORGANIZACJI JAKO METODA SPECYFIKOWANIA WYMAGAŃ

2014-03-18

(c) Jarosław Żeliński 6

MDA i OOADModel Driven Architecture to trzyetapowy proces tworzenia oprogramowania.

OOAD/ DDDZamawiający

Developer

Model jako wymaganie dziedzinowe

Architektura biznesowa

2014-03-18

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

Architektura Korporacyjna i SOA

Misja i Wizja firmy

Proces (aktywność) Proces (aktywność) Proces (aktywność) Proces (aktywność)

Środowisko Środowisko

integracja

DBMX

BO BO

Przypadki Użycia

Usługi Aplikacyjne

SOA

Arch

itekt

ura

Korp

orac

yjna

BOBOBOBO

2014-03-18

(c) Jarosław Żeliński 10

KLASYFIKACJA WYMAGAŃ JAKO SPOSÓB ZARZĄDZANIA NIMI.

2014-03-18

(c) Jarosław Żeliński 11

Model pojęciowywymaganie «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 12

Analiza biznesowa i specyfikowanie wymagań

Model procesów biznesowych

Model przypadków użycia

Model dziedziny

Model Sekwencji

Obiekty 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

Reguły biznesowe

Model CIM (notacja BPMN, SBVR, BMM) Model PIM (notacja UML)

Kontekst projektu (notacja UML) Model PIM (notacja UML)

2014-03-18

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

Czego i skąd wymagać…

2014-03-18

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

Lesson learned czyli co na to praktyka…

50% 50%

80%20%

Harmonogram

KosztOpracowanie CIM i PIM Implementacja

Metody MDA/OOAD

2014-03-18

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

O mnie…

Od 1991 roku w branży IT i zarządzaniaOd 1998 roku jako niezależny analityk, projektant i firma IT-Consulting.PlDziesiątki publikacji w prasie branżowej i gospodarczejCzłonek stowarzyszenia doradców gospodarczychWykł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 przy gabinecie komisji nadzoru finansowego

Projekty analityczne między innymi dla…

Publikacje między innymi w …

2014-03-18