Wymagania w postaci projektu jako metoda obniżania ryzyka projektów programistycznych

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. 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. 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. Taka sytuacja…
2014-03-18 (c) Jarosław Żeliński 4

5. SYSTEMOWA ANALIZA ORGANIZACJI
JAKO METODA SPECYFIKOWANIA
WYMAGAŃ
2014-03-18 (c) Jarosław Żeliński 5

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. 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. (ź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. 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. KLASYFIKACJA WYMAGAŃ JAKO
SPOSÓB ZARZĄDZANIA NIMI.
2014-03-18 (c) Jarosław Żeliński 10

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. 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. 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. 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. Czego i skąd wymagać…
2014-03-18 (c) Jarosław Żeliński 15

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