Dzisiaj bardzo krótko. Bardzo lubię termin “inżynieria wymagań” dlaczego? Po kolei.
Z wiedzy o semantyce i semiotyce wiemy, że zastąpienie pojęcia jego definicją nie może zmienić (nie może, jeżeli definicje są poprawne) znaczenia całości. Więc zastąpmy w zwrocie “inżynieria wymagań” oba słowa ich definicjami (definicje ze słownika j.polskiego PWN):
inżynieria ?projektowanie i konstruowanie obiektów oraz urządzeń technicznych?
wymaganie ?warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać?
Po podstawieniu otrzymamy zwrot mówiący, że “inżyniera wymagań” to:
?projektowanie i konstruowanie? ?warunków, którym ktoś lub coś musi odpowiadać?
Więc nie jest to “zbieranie i porządkowanie” wymagań od użytkowników, więc sesje warsztatowe, burze mózgów itp…. to nie jest “inżynieria wymagań”. A jak? Wymagania się projektuje tak jak przedmioty, de facto, wymaganiem dla developera na placu budowy jest projekt domu, warunkiem przydatności domu jest zgodność z projektem, a projekt powstał w procesie inżynierskim czyli w toku projektowania rozwiązania stanowiącego odpowiedź na cele przyszłego użytkownika (w toku analizy powstaje model biznesowy CIM – Computation Independent Model, na jego podstawie i celu użytkownika powstaje projekt logiki, mechanizmu działania, aplaikcji: model PIM czyli Platform Independent Model, w tym momencie developer realizuje projekt tworząc Platform Specific Model i wykonuje jego implementację; tu polecam opis procesu MDA na OMG.org).
Teraz proponuje przeczytać cytat z WIKI:
Faza wymagań może być podzielona na gromadzenie wymagań (zbieranie wymagań od interesariuszy), analizowanie (sprawdzenie spójności i kompletności), specyfikowanie (dokumentowanie wymagań) oraz zatwierdzanie (upewnienie się, że wymagania są poprawne) (Źródło: Wymaganie (inżynieria) ? Wikipedia, wolna encyklopedia)
Ciekawskim polecam cały wpis w WIKI. Co mamy? Mamy to co mówię studentom”: nie ucz się z WKI!
Zarówno lingwistyka jak i semiotyka, powie Wam, że – o ile nie mówimy o tak zwanych słowach wieloznacznych – branżowe definicje pojęć mogą zawężać słownikowe ich znaczenie ale nie mogą (nie powinny) go zmieniać. Tak więc albo ja się niepotrzebnie czepiam ludzi używających pojęcia “inżynieria wymagań” do opisania prac nie będących inżynierią, albo nie należy uczyć się z WIKI bo wielu ludzi buduje wagę pracy będącej “zbieraniem” zastępując je słowem “inżynieria”.
Literatura naukowa opisująca mity z zakresu skuteczności różnych form pracy grupowej, burz mózgów i intuicji:
- Pułapki myślenia. O myśleniu szybkim i wolnym, Daniel Kahneman
- Psychologia ekonomiczna, Zaleśkiewicz Tomasz
- Psychologia Społeczna, Aronson Elliot, Wilson Timothy D., Akert Robin M.
Witam,
Bardzo podoba mi się Twój wstęp i analiza znaczenia pojęcia “inżyniera wymagań”.
Ja osobiście mam wielki problem tym pojęciem bo dla mnie jest ono trochę zawieszone w pustej przestrzeni – ktoś je dawno temu wymyślił, potem trochę RUP je wchłoną ale ciągle nie jest ono oparte o żaden (znany mi standard) i ciągle organicznie ewoluuje.
Osobiście używam pojęcia “analizy biznesowej”, pomimo tego iż mam inż. przed nazwiskiem 😉 Inżyniera wymagań brzmi bardziej twardo i konkretnie ale w praktyce uważam, że oba pojęcia są mocno zbliżone do siebie, a może nawet tożsame(?). Jednak ogromną różnicą jest fakt, że za analizą biznesową stoi poważna organizacja jaką jest IIBA.
Jarku, czy mógłbyś sprecyzować, czy Twoim zdaniem są jakieś różnice pomiędzy jedyny a drugim pojęciem? Tutaj tylko dodam, że analizę biznesową rozumiem zgodnie z BABOK.
A na koniec tylko dodam, że faktycznie definicja z polskiej Wiki jest takim zlepkiem i uproszczeniem. Widać, że słowo elicytacja jeszcze nie weszło do słownika/żargonu, a o etapie projektowania wymagań przecież nie ma sensu pisać bo i tak, poza chlubnymi wyjątkami, nikt tego nie robi. Cały obszar Requirements Analysis and Design Definition z BABOKa można spokojnie przemilczeć.
Bardzo podoba mi się Twoja postawa piętnowania tego typu “kwiatków”.
Generalnie to moim zdaniem, w IT nie ma sensu uczyć się z polskich źródeł (w tym konkretnym wypadku angielski odpowiednik hasła na WIKI prezentuje się jednak lepiej). Zazwyczaj są one kalką angielskojęzycznych opracowań, nierzadko powielają lub tworzą błędne zrozumienie rzeczy, jak chociażby wielokrotnie prze Ciebie “wałkowane” modelowanie relacyjnej bazy danych przy użyciu diagramu klas.
Pozdrawiam serdecznie,
Paweł
Ja osobiście nie używam pojęcia “inżynieria wymagań” z uwagi na to jak jest stosowane a przez to i “potocznie” rozumiane. Artykuł zaś napisałem z czystej przekory i chęci prowokacji by to uzmysłowić czytelnikom :). Słowo wymagania w moich dokumentach raczej jest używane łącznie jako “wymagania biznesowe” (coś czego potrzebuje biznes do realizacji celów biznesowych) ale unikam go jak tylko mogę, wole iść tropem: (1) Analiza Biznesowa, której produktem jest model procesów biznesowych i reguły biznesowe ze słownikiem pojęć, (2) Specyfikacja wymaganych usług aplikacji jako Przypadki Użycia wraz z ograniczeniami (reguły biznesowe przechodzą 1:1 jako logika biznesowa), (3) model dziedziny systemu jeżeli zamawiane są dedykowane komponenty.
Trzymam się tego od lat i sprawdza się doskonale. Trzymam się styku BABoK + OMG/MDA. Niestety uczyć się pozostaje z oryginalnych źródłowych dokumentów, jeżeli bierzemy się za opracowania to warto skupiać się na książkach opisujących cudze doświadczenia, najlepsze praktyki itp. ale raz zgodne z dokumentami źródłowymi dwa, unikam “pomysłów” objętych patentami i własnymi, z reguły kiepsko sformalizowanymi notacjami (np. TOGAF i ArchiMate).
Modelowanie danych diagramem klas UML to modelowy przykład niekompetencji :), jest takich więcej. niestety firma SPARX ma tu swój potężny wkład, np. “czas jako aktor” czy “systemowe przypadki użycia”…. “wspierający aktor” itp. bełkot….. w UML tego nie znajdziesz a nie są to poprawnie zdefiniowane profile.
Ha, czyli trafiony zatopiony jeśli chodzi o pojęcie “inżynieria wymagań” 🙂
Jeśli chodzi o TOGAF i ArchiMate to osobiście uważam je za bardzo dobre. Nie do końca rozumiem co masz myśli mówiąc o ArchiMate, że jest “kiepsko sformalizowaną notacją”. Czytałem Twojego bloga i zauważyłem, że na początku chwaliłeś i używałeś ArchiMate, potem od niego odszedłeś. Jakie masz merytoryczne zastrzeżenia wobec niego (poza licencją)?
Gdyby specyfikacja UMLa była napisana tak dobrze i przystępnie jak ta od ArchiMate to prawdopodobnie nie byłoby tak wielu problemów, bo ludzie by po prostu rozumieli UMLa – a tak co książka to inna interpretacja.
Temat licencji jest generalnie kiepski w TOG (The Open Group). Organizacja może używać TOGAFa i ArchiMate za darmo do własnych “wewnętrznych” celów. Ale gdy chce na nim zarabiać to musi wykupić komercyjną licencję. Tutaj pojawia się problem dla takich ludzi jak my, czyli konsultantów. Teoretycznie jeśli dla jakiegoś klienta wykonamy jakieś “delivarable” zgodnie z TOGAF albo wykonamy diagram w ArchiMate to powinniśmy ją mieć, choć nie jestem pewien, bo może jesteśmy objęci przez licencje organizacji? Pewnym jest, że jak chcesz zrobić szkolenie z TOGAFa lub ArchiMata to musisz mieć licencję komercyjną. I tutaj jako jednoosobowa firma musisz zapłacic tyle samo, co organizacja, która zarabia do 25 milionów dolarów rocznie! Przydałby się jakiś upust!
Jak już wspomniałem, specka od UMLa jest napisana strasznie, totalnie nieprzystępnie dla ludzi. To nie tylko Sparx EA łamie zasady. Przypuszczam, że Sparx zaimplementował oczekiwania rynku, a to, że nie są zgodne ze specką… coż klienta nasz pan.
Piszesz ?wspierający aktor? itp. bełkot – zgadzam się, sięgnijmy zatem do literatury:
1. ksiazka Learning UML 2 – rodzial 2.1.5. Use Case Descriptions, wspomina o Secondary Actor
2. The Object Primer – rodzial 2.1.5. Use Case Descriptions tez wspomina o dodatkowych aktorach
3. Use Cases – Patterns and Blueprints – tutaj w rozdziale 5 też autor pisze o interakcjach miedzy aktorami i (o zgrozo) na diagramie przypadkow uzycia pokazuje flow komunikacji za pomocą strzałek w asocjacjach.
4. Microsoft https://msdn.microsoft.com/en-us/library/dd409427(VS.100).aspx – na drugim diagramie elementy nr 8 i 10 są niezgodne ze specyfikacja UMLa.
Mam wymieniać dalej? 🙂 a to tylko jeden, zdawać by się mogło, prosty diagram. UML to nie matematyka, jeśli ludzi go nie rozumieją to niekoniecznie wina ludzi…
Dodaktowo biznesowe i systemowe przypadku użycia to wymysł RUPa a nie Sparxa. Jak wiesz wtedy nie było BPMNa wiec jakoś musieli sobie radzić…
I znów mi wyszedł laborat, przepraszam 🙂
Początkowo ArchiMate mnie także uwiódł, bo wyglądało że na poziomie biznesowym dam rade w 100% z ta notacją, okazało się jednak, że autorzy przyznali, ze bez BPMN i UML nie da się zrobić analizy top-down bo ArchiMate to tylko “wysoki poziom abstrakcji”, po drugie operowanie pojęciem model danych na tym poziomie uważam jednak za nieporozumienie. Do tego niestety w ArchiMate definicje pojęć “funkcja” czy “proces” są jednak mętne i nieodseparowane podobnie jak “rola” i “aktor”. Na koniec dodam, że nigdy nie miałem problemu z tym by mój klient przeczytał diagram BPMN, z ArchiMate bywały problemy. Przyznaję także, że jestem nieco uprzedzony do zamkniętych standardów w nauce. Ale kluczowym powodem jest to, że skoro i tam muszę użyć w projektach BPMN i UML (co sami twórcy ArchiMate przyznają) to po co wprowadzać kolejna notację do metodyki :)?
Co do RUP’a owszem być może byli pierwsi, ale kultywowanie tej “tradycji” w 2015 roku to masakra :), Co do literatury książek z UML ok, przywołujesz czyjeś pomysły, których autorzy nie uzasadnili inaczej niż “do celu … użyć mozna”… ja także podchodzę do ich nawet nie z rezerwą a pewnym “niesmakiem” bo wprowadzają bałagan pojęciowy a nie raz wręcz fałszują oryginał, owe transakcje między aktorami itp.. to już całkowita masakra. Microsoft tłumaczy się gdzieniegdzie, że ich frameworki to pewnej profile UML ale mam wrażenie, że dobudowują ideologię :).
Praktyka pokazuje, ze proste jest piękne, Ockham miał rację a ja mam w głowie cytat z pewnej (nie pamiętam której) książki: “dodawanie nowych symboli i definicji do UML, kłócących się z jego semantyką, to przejaw niezrozumienia: to czego analityk nie zrozumiał ubrał w nowy symbol”. Klasyką tego podejścia jest “czas jako aktor” albo “wewnętrzny systemowy przypadek użycia”…
🙂 też mi długie wyszło …
Co do licencji ArchiMate, jednak okazuje się, że w przypadku samozatrudnionych konsultantów (naszym) możemy legalnie świadzyć usługi architektoniczne bez wykupienia licencji komercyjnej:
“For the avoidance of doubt and purposes of this license, individual contractors, who do not represent
themselves or offer their services commercially as architecture practitioners, shall be regarded as
?permanent employees? of the Licensee Organization.”
oraz
Wiem, ale niektórzy klienci rezygnują z uwagi na ryzyko, a ja wcale im nie odradzam :), w 100% bazuje na OMG.org
Tematy ciekawe to i dyskusja długa 🙂
Dzięki bardzo i pozdrawiam,
Paweł
Może dla programistów i analityków z branży IT ten wstęp ma sens. Ale inżynieria, to nie jest tylko projektowanie i konstruowanie, a projekt domu w żadnym wypadku nie jest wymaganiem! W rozwoju każdego produktu wymagania majątakie samo znaczenie. Projekt domu powstaje w oparciu i wymagania, podobnie jak projekt samochodu.
W inżynierii:
– dla projektanta wymaganiem są oczekiwania przyszłego użytkownika,
– dla wykonawcy wymaganiem jest projekt tego co ma zrobić.
Pisze Pan “Projekt domu powstaje w oparciu o wymagania, podobnie jak projekt samochodu”, i to jest prawda, a konkretny dom/samochód powstaje (robi to już kto inny) na podstawie projektu, który jest wymaganiem wobec stawiającego dom, produkującego samochody. Słowo wymaganie ma prostą definicję (słownik języka polskiego): ?warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać?. Użytkownik określa swoje warunki, musi je spełnić projekt projektanta. To co dostarczy wykonawca, też musi spełniać pewien warunek: zgodność z projektem. Można to nazwać łańcuchem wymagań. Dlatego od lat literatura przedmiotu (inżynieria systemów, polecam stromy INCOSE)) zawiera pojęcie “projekt jako wymaganie wobec developera”.