Jedno wymaganie – kilka perspektyw

Wpadł mi nie­daw­no do skrzyn­ki mailo­wej kolej­ny arty­kuł ser­wi­su Modern Analyst, cytat:

If you cre­ate only one view of the requ­ire­ments, you must belie­ve it. You have no other cho­ice. If you deve­lop mul­ti­ple views, tho­ugh, you can com­pa­re them to look for discon­nects that reve­al errors and dif­fe­rent inter­pre­ta­tions. (źr. Why Create Multiple Requirements Views? > Business Analyst Community & Resources | Modern Analyst > Business Analyst Articles & Systems Analysis Articles | Modern Analyst).

Autor suge­ru­je by łączyć wyma­ga­nia funk­cjo­nal­ne z przy­pad­ka­mi uży­cia, testa­mi, mode­la­mi. W dużym uprosz­cze­niu: jeże­li mamy tyl­ko jed­ną per­spek­ty­wę wyma­gań (np. w posta­ci listy wyma­gań funk­cjo­nal­nych i poza­funk­cjo­nal­nych) musi­my im wie­rzyć bo nie mamy ich wery­fi­ka­to­ra (nie mamy inne­go wyj­ścia). Troszkę to łącze­nie każ­dy z każ­dym” chy­ba jed­nak nie ułatwia:

źr. http://​www​.moder​na​na​lyst​.com/

Problem kom­plet­no­ści i spój­no­ści wyma­gań jest dość trud­ny do roz­wią­za­nia. Wymagania nie­kom­plet­ne i nie­spój­ne potra­fią zaś zabić pro­jekt, wady spe­cy­fi­ka­cji (takie jak nie­kom­plet­ność i nie­spój­ność) skut­ku­ją odkry­wa­niem ich w trak­cie pro­jek­tu, rośnie w nie­kon­tro­lo­wa­ny spo­sób zło­żo­ność projektu.

Jeżeli wypra­cu­je­my wię­cej per­spek­tyw, może­my je skon­fron­to­wać i porów­nać, wykry­wa­jąc ewen­tu­al­ne nie­ści­sło­ści i błę­dy. Także [[BABoK]] (rodem z [[IIBA]]) zale­ca utrzy­my­wa­nie tak zwa­nej śla­do­wal­no­ści, to jest wywo­dze­nia np. wyma­gań na opro­gra­mo­wa­nie z wyma­gań biz­ne­so­wych, a tych z celu pro­jek­tu. Nadal jed­nak mamy tyl­ko jed­no źró­dło dla każ­de­go wyma­ga­nia. To rodzi pew­ne ryzy­ko, gdyż brak wery­fi­ka­to­ra powo­du­je, że ryzy­ko błę­du pozostaje.

Od kil­ku lat sto­su­je meto­dę pole­ga­ją­cą na testo­wa­niu lub spe­cy­fi­ko­wa­niu reli­za­cji wyma­gań. Rok 2008, na zakoń­cze­nie arty­ku­łu IEEE830-1998 ? czy pro­du­ku­je dobre wyma­ga­nia? napisałem:

Metodyka, któ­rą stosuję

  1. Wymagania funk­cjo­nal­ne to przy­pad­ki uży­cia sys­te­mu; Przypadki uży­cia sys­te­mu to czyn­no­ści wyse­lek­cjo­no­wa­ne z mode­lu pro­ce­sów na bazie zakre­su projektu.
  2. Wymagania nie­funk­cjo­nal­ne to ogra­ni­cze­nia nakła­da­ne na poszcze­gól­ne przy­pad­ki uży­cia (mogą być gru­po­wa­ne np. mak­sy­mal­ny czas odpo­wie­dzi sys­te­mu nie może prze­kro­czyć 1 s. z wyjąt­kiem rapor­tów, gdzie mak­sy­mal­ny czas odpo­wie­dzi to 1 minuta)
  3. Wymagania dzie­dzi­no­we opi­sy­wa­ne są mode­lem dzie­dzi­ny sys­te­mu (dia­gram klas lub ERD)

c.d. kie­dyś nastąpi?

Tak więc mamy ciąg dal­szy :). Wspomniałem o wyma­ga­niach dzie­dzi­no­wych. Osobiście trak­tu­ję je wła­śnie jako trze­cią nogę” wspie­ra­ją­cą model wyma­gań. Funkcjonalność (usłu­ga sys­te­mu) mówi nam cze­go ocze­ku­je użyt­kow­nik, jed­nak usłu­ga sys­te­mu” opi­su­je sys­tem jako tak zwa­ną czar­ną skrzyn­kę”. Jeżeli uzu­peł­ni­my opis wyma­gań ele­men­ta­mi mode­lu dzie­dzi­ny, doda­my wery­fi­ka­tor w posta­ci opi­su wnę­trza tej czar­nej skrzyn­ki (wyma­ga­my nie tyl­ko two­rze­nia fak­tu­ry VAT” ale defi­niu­je­my jej struk­tu­rę, to się nazy­wa opis bia­łej skrzynki”).

Jak wspo­mnia­łem swe­go cza­su, opra­co­wu­jąc wyma­ga­nia na goto­we i zaawan­so­wa­ne opro­gra­mo­wa­nie nie ma sen­su jego pro­jek­to­wa­nie. Zbyt szcze­gó­ło­wa spe­cy­fi­ka­cja zbli­ża nas do pro­jek­tu, a my chce­my jed­nak coś goto­we­go (ma być taniej i szybciej).

Standardowo, spe­cy­fi­ku­jąc wyma­ga­nia, nale­ży sku­pić się na tym do cze­go będzie­my uży­wa­li opro­gra­mo­wa­nia a nie na tym jak ono to robi. Jednak do cze­go” ozna­cza co będzie­my two­rzyć i prze­twa­rzać”. Co więc robić? Proszę popatrzeć:

Tak więc wymaganie:

  1. koja­rzy­my z reali­zu­ją­cym je mode­lem (przy­pad­kiem uży­cia, pro­ce­sem, ele­men­tem dziedziny),
  2. koja­rzy­my z testem spraw­dza­ją­cym czy zosta­ło speł­nio­ne (z pomo­cą dobra­ne­go sce­na­riu­sza testowego).

Powszechnie posłu­gu­je­my się wyma­ga­nia­mi funk­cjo­nal­ny­mi. Czym jest wyma­ga­nie dzie­dzi­no­we? Wyobraźmy sobie, że chce­my opi­sać wszyst­kie meto­dy i sce­na­riu­sze wysta­wie­nia fak­tu­ry VAT. Będzie ich bar­dzo dużo, zapew­ne moż­li­we będą takie, któ­rych nie wymy­śli­li­śmy”. Bezpieczniej jest opi­sać fak­tu­rę VAT wraz z regu­ła­mi rzą­dzą­cy­mi jej poszcze­gól­ny­mi pola­mi, zamiast uznać ją za czar­ną skrzyn­kę” i pró­bo­wać opi­sać meto­dą jak moż­na jej użyć”.

Młotek moż­na opi­sać tym do cze­go będzie uży­wa­ny” (przy­pad­ki uży­cia) lub jak wyglą­da”. Nie raz dru­ga meto­da jest bez­piecz­niej­sza, jed­nak jest to już pro­jek­to­wa­nie i nale­ży to robić świa­do­mie. Czy to źle? Nie, bo nie raz zapro­jek­to­wa­nie jest mniej ryzy­kow­ne niż opis do cze­go” (zamiast zło­żo­ne­go opi­su wie­lu zasto­so­wań młot­ka, pro­ściej jest go narysować).

Zawsze, przy każ­dym wyma­ga­niu, nale­ży pod­jąć decy­zję, czy reali­za­cja wyma­ga­nia przez dostaw­cę sta­no­wi ryzy­ko (i jakie). Sami pro­jek­tu­je­my reali­za­cję (two­rzy­my model) zawsze, gdy to ryzy­ko jest za duże by je akcep­to­wać. Podobnie trak­tu­je­my testy. Projektujemy je, gdy koszt nie­speł­nie­nia dane­go wyma­ga­nia prze­kra­cza dopusz­czal­ny poziom. Testem może być tak­że model (np. pro­ce­su biznesowego).

Takie podej­ście powo­du­je, że zanim jesz­cze dotknie­my goto­we­go pro­duk­tu (tu nie­ste­ty już po jego wybo­rze) może­my po pierw­sze: prze­te­sto­wać samą spe­cy­fi­ka­cję a po dru­gie prze­ka­zać poten­cjal­ne­mu dostaw­cy (na eta­pie zapy­ta­nia) peł­ną infor­ma­cję o tym, cze­go ocze­ku­je­my od pro­duk­tu i jak to sprawdzimy.

Powyższe podej­ście w posta­ci «full wypas” może być pra­co­chłon­ne, dla­te­go moż­li­we są warian­ty pośred­nie, czy­li tyl­ko dla wyma­gań ozna­czo­nych jako ryzy­kow­ne budu­je­my testy lub mode­le, jed­nak mamy narzę­dzie do pano­wa­nia nad tym ryzy­kiem. Po dru­gie zysku­je­my narzę­dzie do wery­fi­ka­cji, odbiór opro­gra­mo­wa­nia nie będzie spraw­dza­niem pokaź­nej i ryzy­kow­nej zara­zem listy dzie­sią­tek cech, będzie jaz­dą prób­ną na sucho”, a więc rela­tyw­nie tanią i pew­ną meto­dą testów: dostaw­ca dekla­ru­je (ofer­ta na nasze zapy­ta­nie) zgod­ność z naszy­mi wyma­ga­nia­mi, a te są wery­fi­ko­wal­ne. Należy roz­wa­żać zawsze koja­rze­nie mode­li z testami.

Kiedy jesz­cze pisze­my reali­za­cję”? Gdy chce­my pozo­stać jej auto­ra­mi i chro­nić nasz know-how.

Managing Requirements from a Business Analyst or an Enterprise Architect perspective using BABOK 2.0 and/or TOGAF 9

Na począ­tek pod­su­mo­wa­nie cyto­wa­ne­go artykułu:

BABOK 2.0 sets up a fra­me­work for the requ­ire­ments deve­lop­ment and mana­ge­ment, which seems to appe­ar as a stan­dard used by many orga­ni­za­tions aro­und the world. Between TOGAF 9 and BABOK 2.0, the­re is almost 1:1 cor­re­spon­den­ce but the­re may be more deta­ils and acti­vi­ties in the first one. TOGAF is a metho­do­lo­gy whe­re­as the BABOK is metho­do­lo­gy agno­stic, so it can be tric­ky to trans­la­te betwe­en the two but nothing pre­vent an Enterprise Architecture team to use this ana­lo­go­us technique.

If an orga­ni­za­tion fol­lows the TOGAF metho­do­lo­gy and Business Analysts use BABOK, the later will pro­vi­de a lot of use­ful infor­ma­tion, as a refe­ren­ce; BABOK won’t give you direc­tion for an Enterprise Architecture.

Sources: Chapter 4 IIBA?s BABOK 2.0, TOGAF 9 (źr. Managing Requirements from a Business Analyst or an Enterprise Architect per­spec­ti­ve using BABOK 2.0 and/or TOGAF 9.)

W kil­ku zda­niach. Diagram poni­żej obra­zu­je dwa róż­ne spoj­rze­nia na to samo”:

BABoK vs. TOGAF
BABoK vs. TOGAF

Autor arty­ku­łu porów­nu­je obie te spe­cy­fi­ka­cje i poka­zu­je, że są prak­tycz­nie zgod­ne w 100%, nie licząc meto­dy pre­zen­ta­cji i per­spek­ty­wy. W obu przy­pad­kach ma miej­sce ana­li­za, porów­na­nie i spe­cy­fi­ka­cja celów biz­ne­so­wych oraz przy­po­rząd­ko­wa­nie ich do narzę­dzi (głów­nie ale nie tyl­ko IT) wspie­ra­ją­cych reali­za­cję tego celu. Jeżeli uznać, że spe­cy­fi­ka­cja coś opi­su­je, to zależ­nie od fazy pro­jek­tu jest spe­cy­fi­ka­cją potrzeb a potem spe­cy­fi­ka­cją tego co się posia­da (jak uda się zakup ;)).

Sprawna Inżynieria Oprogramowania: Ekstremalna obiektowość

Jestem gorą­cym fanem blo­gów dobrych (tak sądzę, że są ;)) pro­gra­mi­stów. Dlaczego? Bo to oni się męczą z moimi pro­jek­ta­mi. O czym powi­nien pamię­tać dobry ana­li­tyk pro­jek­tant? O dwóch rze­czach (zresz­tą o tym powi­nie pamię­tać każ­dy): po pierw­sze nie zapo­mi­naj kim jest Twój klient – mów do nie­go jego języ­kiem, po dru­gie jak coś two­rzysz dla swo­je­go klien­ta to nie po to by on musiał to jesz­cze raz po Tobie zro­bić po swojemu.

Analitycy jako zasoby

W pro­jek­tach infor­ma­tycz­nych naj­czę­ściej spo­ty­ka­my: ana­li­ty­ka wyma­gań (AW), ana­li­ty­ka sys­te­mo­we­go (AS), dewe­lo­pe­ra w tym archi­tek­ta sys­te­mu (D). W zasa­dzie trud­no powie­dzieć co jest pro­duk­tem dwóch pierw­szych bo Deweloper odda­je dzia­ła­ją­ce opro­gra­mo­wa­nie. Najczęściej AW dostar­cza jakiś opis tego cze­go ocze­ku­je klient, AS porząd­ku­je to co zro­bił AW np. z pomo­cą przy­pad­ków uży­cia a D bie­rze to do ręki i musi zapro­jek­to­wać i wyko­nać opro­gra­mo­wa­nie. Jak widać, odpo­wie­dzial­ność za to co powsta­nie jest roz­my­ta. Klient naj­pierw prze­ka­zu­je swo­je ocze­ki­wa­nia AW zaś otrzy­mu­je pro­dukt od D. Konia z rzę­dem temu, kto mi powie jak tego doko­nać bez per­ma­nent­nych ite­ra­cyj­nych wyja­śnień i bom­bar­do­wa­nia Klienta pyta­nia w rodza­ju co Państwo mie­li na myśli pisząc/mówiąc, że …”.

Od koń­ca. By powsta­ło opro­gra­mo­wa­nie (zakła­dam na dziś, że meto­da­mi obiek­to­wy­mi) musi powstać jego spe­cy­fi­ka­cja, pro­jekt któ­ry dokład­nie opi­su­je co mają zako­do­wać pro­gra­mi­ści. Bez tego nie wia­do­mo ani co ma powstać ani ile to wyma­ga pra­cy. Aby powsta­ła spe­cy­fi­ka­cja musi powstać opis logi­ki sys­te­mu bo tego wła­śnie ocze­ku­je Klient. Aby ta logi­ka powsta­ła trze­ba dokład­nie zro­zu­mieć to cze­go klient ocze­ku­je, jako że ocze­ku­je narzę­dzia wspo­ma­ga­ją­ce­go zarzą­dza­nie jego fir­mą, nale­ży tę fir­mę dokład­nie opi­sac a wcze­śniej zrozumieć.

W czym pro­blem? Mając trzy role w pro­jek­cie: AW, AS i D powsta­je zaba­wa w głu­chy tele­fon, któ­ra koń­czy się tym, że kon­tak­tu­ją się z Klientem wszy­scy bo opis słow­ny wyma­gań z regu­ły jest nie­pre­cy­zyj­ny i nie­kom­plet­ny. AS na bazie tego opi­su coś pro­jek­tu­je, D two­rzy pierw­szą wer­sje sys­te­mu. Klient to dosta­je i zgła­sza uwa­gi i ocze­ki­wa­nia, bo to tak na praw­dę jego pierw­szy kon­takt z pro­duk­tem. Proces ten zna każ­dy kto brał udział w takim pro­jek­cie (pozo­sta­łych prze­strze­gam przez takim podejściem).

Powyżej opi­sa­ny bieg wyda­rzeń to zaso­bo­we (silo­so­we) podej­ście do pro­jek­tu: jak użyć ludzi o posia­da­nych kompetencjach.

Analityk i deweloper jako właściciele procesów

Jak nale­ża­ło się spo­dzie­wać, musia­ło to dopro­wa­dzić do szu­ka­nia roz­wią­za­nia. Podobnie jak w zarzą­dza­niu w innych obsza­rach, zaczy­na­my mówić o pro­ce­sie wytwa­rza­nia opro­gra­mo­wa­nia”. A sko­ro mowa o pro­ce­sie to powin­ny się poja­wić pro­duk­ty poszcze­gól­nych pod-pro­ce­sów, ich wyko­naw­cy są wtór­ni wobec pro­duk­tów. Najpierw defi­niu­je­my pro­dukt potem wska­zu­je­my odpowiedzialnego.

W pro­ce­sie wytwa­rza­nia opro­gra­mo­wa­nia potrzeb­ne sa trzy produkty:

  1. opis celu biz­ne­so­we­go i stra­te­gii jego osią­gnię­cia, jed­nym z narzę­dzie zapew­ne będzie jakieś oprogramowanie,
  2. pro­jekt opro­gra­mo­wa­nia, nale­ży je zaprojektować,
  3. wyko­na­ne (dostar­czo­ne) oprogramowanie.

Mamy więc trzy ocze­ki­wa­ne pro­duk­ty czy­li trzy pro­ce­sy: ana­li­za biz­ne­so­wa, pro­jek­to­wa­nie, wyko­na­nie (imple­men­ta­cja). Projekt jest ści­śle powią­za­ny z ana­li­zą biz­ne­so­wa, gdyż powsta­je na bazie niej i jej peł­ne­go zro­zu­mie­nia, nasu­wa to wnio­sek, że jed­na oso­ba powin­na odpo­wia­dać za pro­jekt i dobrze jest jeśli będzie to autor ana­li­zy biz­ne­so­wej. Jakie roz­wią­za­nie jest więc skuteczne?

Tym roz­wią­za­niem wyda­ja się być:

  1. meto­dy obiek­to­we ana­li­zy, pro­jek­to­wa­nia i implementacji,
  2. podział pro­ce­su na dwa eta­py i dwie role: opra­co­wa­nie pro­jek­tu logi­ki sys­te­mu i implementacja,
  3. [[wzo­rzec pro­jek­to­wy MVC]] i [[pro­jek­to­wa­nie meto­dą DDD]].

W dużym uproszczeniu:

  1. meto­dy obiek­to­we pozwa­la­ją na uży­wa­nie od same­go począt­ku tego same­go spo­so­bu opi­su (mode­lo­wa­nia) roz­wią­za­nia, któ­re powsta­je w mia­rę postę­pów ana­li­zy, zapis tego cze­go ocze­ku­je Klient to Przypadki Użycia (czar­na skrzyn­ka) oraz Model Dziedziny (pro­jekt – bia­ła skrzynka),
  2. do two­rze­nia opro­gra­mo­wa­nia uży­wa się obec­nie naj­czę­ściej fra­me­wor­ków bazu­ją­cych na [[wzor­cu MVC]] dla któ­re­go [[Model Dziedziny]] zapro­jek­to­wa­ny zgod­nie z DDD, jest goto­wym pro­jek­tem logi­ki kom­po­nen­tu Model z MVC zaś Przypadki Użycia to wyma­ga­nia na inter­fejs użyt­kow­ni­ka opi­sa­ny jak V w MVC (kom­po­nent C – kon­tro­ler – odpo­wia­da za ste­ro­wa­nie apli­ka­cją i reali­za­cję wyma­gań poza-funkcjonalnych).

Można wiec powie­dzieć, że kie­ru­nek jest taki:

Tak więc z trzech, nie­ja­sno okre­ślo­nych ról two­rzą sie dwie:

  1. Analityk Biznesowy, któ­re­go rolą jest dostar­czyć wyma­ga­nia funk­cjo­nal­ne (przy­pad­ki uży­cia wraz z ogra­ni­cze­nia­mi) oraz Model Dziedziny,
  2. Deweloper, któ­re­go rolą jest dostar­cze­nie opro­gra­mo­wa­nia imple­men­tu­ją­ce­go tak okre­ślo­ne Wymagania, Developer ma” Architekta Systemu czy­li pro­jek­tan­ta implementacji.

Jest to pro­mo­wa­ny” przez [[IIBA w BABoK]] pro­ces i zakres kompetencji.

Teraz kolej na dono­sy z inne­go blo­ga, jest to blog programisty:

Jeff Bay pro­po­nu­je w nim 9 reguł doty­czą­cych two­rze­nia kodu (przy­kła­dy są w javie, ale więk­szość reguł odno­sić się może do w mia­rę dowol­ne­go języ­ka, szcze­gól­nie OO). Są to:

  • Tylko jeden poziom zagłę­bie­nia na metodę
  • Nie uży­waj sło­wa klu­czo­we­go else
  • Opakowuj wszyst­kie pry­mi­ty­wy i Stringi (w kla­sy o spe­cy­ficz­nej dla zasto­so­wa­nia nazwie)
  • Używaj tyl­ko jed­nej krop­ki na linię
  • Nie skra­caj nazw
  • Pilnuj wszyst­kie encje by były małe
  • Nie uży­waj klas o wię­cej niż dwóch polach
  • Klasa któ­rej polem jest kolek­cja nie powin­na mieć żad­nych innych pól (opa­ko­wy­wa­nie kolek­cji w kla­sy spe­cy­ficz­ne dla kon­tek­stu wykorzystania)
  • Nie uży­waj getterów/setterów/własności

(źr. Sprawna Inżynieria Oprogramowania: Ekstremalna obiektowość.)

Jeżeli uznać, że to wyma­ga­nia w ogó­le na pro­jekt obiek­to­wy to są to wyma­ga­nia dla mnie: Analityka Biznesowego, na to jak ma wyglą­dać Model Dziedziny Systemu.

Po co to wszyst­ko? Bo tu nie ma głu­che­go tele­fo­nu, pro­dukt powsta­je w pierw­szej ite­ra­cji i każ­dy dokład­nie wie za co odpo­wia­da. Całość trwa kró­cej i jest mniej kosztowna.

P.S.

A tym jak taki pro­dukt, Wymagania, powsta­je pisa­łem już wcze­śniej, o tym jak się to imple­men­tu­je niech piszą programiści 🙂

P.S. 2

Polecam tak­że inne cie­ka­we spoj­rze­nie na ten pro­blem w arty­ku­le Analityk sys­te­mo­wy – łącz­nik dwóch świa­tów. Tu fak­tycz­nie sta­je się pro­ble­ma­tycz­ne stwier­dze­nie kim jest, a kim nie, ana­li­tyk sys­te­mo­wy. Być może Analityk Systemowy jest wła­ściw­szym ter­mi­nem, jed­nak ja boje się tego, że powszech­nie koja­rzo­ne z infor­ma­ty­ką poję­cie sys­tem” zabu­rza tak poj­mo­wa­ne zna­cze­nie ana­li­zy sys­te­mo­wej”, któ­ra nie koniecz­nie doty­czy sys­te­mów IT. Modelowanie biz­ne­su (firm, orga­ni­za­cji) meto­da­mi zna­ny­mi z ana­li­zy sys­te­mo­wej ([[ogól­na teo­ria sys­te­mów]]) jest chy­ba jed­nak ana­li­zą biz­ne­so­wą (tego biz­ne­su), ale mogę się mylić…