Wzorzec CRUD dla przypadków użycia i mikroserwisy

Regularnie spo­ty­kam się z mon­stru­al­ny­mi spe­cy­fi­ka­cja­mi: naj­pierw wyma­gań” a potem przy­pad­ków uży­cia”: dzie­siąt­ki, set­ki (o ich ilo­ści napi­sa­łem tu). Na ich pod­sta­wie powsta­ją wyce­ny – nie mniej kosmicz­ne. Jednak jeże­li zesta­wić to z bada­nia­mi pro­jek­tów i oce­ną, że jed­ną z klu­czo­wych przy­czyn pora­żek jest nad­mier­na zło­żo­ność i nie­jed­no­znacz­ność spe­cy­fi­ka­cji wyma­gań, a potem same­go pro­jek­tu i jego zakre­su oraz utra­ta pano­wa­nia nad tym zakre­sem, to może war­to się nad tym pochylić?

Kluczem jest defi­ni­cja wyma­ga­nia i czę­sto są nimi wła­śnie przy­pad­ki uży­cia. Pojęcie przy­pad­ku uży­cia (UML) i usłu­gi (SoaML):

Przypadek uży­cia (UML, Superstructure v.2.4.1.): A use case is the spe­ci­fi­ca­tion of a set of actions per­for­med by a sys­tem, which yields an obse­rva­ble result that is, typi­cal­ly, of value for one or more actors or other sta­ke­hol­ders of the sys­tem.

Usługa (SoaML, v.1.0.1.): Service is defi­ned as the deli­ve­ry of value to ano­ther par­ty, ena­bled by one or more capa­bi­li­ties. Here, the access to the servi­ce is pro­vi­ded using a pre­scri­bed con­tract and is exer­ci­sed con­si­stent with con­stra­ints and poli­cies as spe­ci­fied by the servi­ce contract.

Tak więc przy­pa­dek uży­cia jako efekt daje okre­ślo­ny, war­to­ścio­wy rezul­tat. Warto teraz w tym miej­scu pod­kre­ślić, że SOA (patrz spe­cy­fi­ka­cja) zakła­da, że usłu­ga jako efekt (pro­dukt) daje Real World Effect defi­ned as servi­ce ope­ra­tion post con­di­tion” co jest o tyle istot­ne, że ana­lo­gicz­nie koń­czy się przy­pa­dek uży­cia (przy­po­mnę, że post con­di­tion” to sta­bil­ny stan sys­te­mu po wyko­na­niu operacji).

Popatrzmy teraz na poję­cie czyn­no­ści w BPMN:

Aktywność a czyn­ność: (BPMN, v.2.0) An Activity is work that is per­for­med within a Business Process. An Activity can be ato­mic or non-ato­mic (com­po­und). The types of Activities that are a part of a Process are: Task, Sub-Process, and Call Activity, which allows the inc­lu­sion of re-usa­ble Tasks and Processes in the dia­gram. However, a Process is not a spe­ci­fic gra­phi­cal object. Instead, it is a set of gra­phi­cal objects. The fol­lo­wing sec­tions will focus on the gra­phi­cal objects Sub-Process and Task. […] A Task is an ato­mic Activity within a Process flow. A Task is used when the work in the Process can­not be bro­ken down to a finer level of detail.

Tu zaczy­na się prag­ma­ty­ka biz­ne­so­wa, czy­li defi­ni­cja poję­cia pro­ces biz­ne­so­wy, któ­ra zakła­da, że pro­ces biz­ne­so­wy (tak­że ele­men­tar­ny, ato­mo­wy) to czyn­ność lub łań­cuch logicz­nie powią­za­nych czyn­no­ści (aktyw­ność), two­rzy pro­dukt mają­cy war­tość dla odbior­cy tego pro­duk­tu (pro­dukt musi się nada­wać do biz­ne­so­we­go wyko­rzy­sta­nia). Ta defi­ni­cja jest nie­mal­że kopia defi­ni­cji przy­pad­ku uży­cia. Procesem biz­ne­so­wym jest KAŻDA aktyw­ność wraz z jej samo­dziel­nie przy­dat­nym biz­ne­so­wo pro­duk­tem (para aktyw­ność i jej pro­dukt, dla­te­go w BPMN nie ma jed­nej iko­ny na pro­ces biz­ne­so­wy”). Jak widać, te trzy poję­cia: przy­pa­dek uży­cia apli­ka­cji, usłu­ga apli­ka­cji oraz ele­men­tar­ny pro­ces biz­ne­so­wy (pod­kre­ślam, że pro­jek­ty IT dla biz­ne­su mają biz­ne­so­wy kon­tekst co nada­je ści­ślej­sze zna­cze­nia tym trzem poję­ciom), mają nie­mal­że toż­sa­me defi­ni­cje (zresz­tą OMG dąży w tym wła­śnie kie­run­ku). Popatrzmy tu:

The majo­ri­ty of today­’s SOA design tech­ni­qu­es 1,2,3 are cen­te­red aro­und defi­ni­tion of servi­ces. They use 1se­rvi­ce-orien­ted decom­po­si­tion, based on the busi­ness pro­ces­ses, enter­pri­se business/functional model, requ­ired long term archi­tec­tu­ral goals and reu­se of the exi­sting enter­pri­se func­tio­na­li­ty. (Incorporating Enterprise Data into SOA).

Kluczem jest suge­stia (uzna­nie), że ele­men­tar­nym poję­ciem do dekom­po­zy­cji funk­cjo­nal­nej jest poję­cie ele­men­tar­nej (ato­mo­wej) usłu­gi (i nie jest nią jed­na linia pro­gra­mu!) będą­cej tak­że ele­men­tar­nym pro­ce­sem biz­ne­so­wym. Popatrzmy na dia­gram obra­zu­ją­cy archi­tek­tu­rę SOA (pocho­dzą­cy z tego same­go artykułu):

SOA implemetation

Mamy tu, mię­dzy inny­mi, trzy waż­ne war­stwy (tu dru­gą, trze­cią i czwar­tą od góry), są to odpo­wied­nio: pro­ce­sy biz­ne­so­we, usłu­gi apli­ka­cyj­ne (ta war­stwa to abs­trak­cja) oraz apli­ka­cje świad­czą­ce te usłu­gi. Mamy więc mapo­wa­nie ele­men­tar­nych ato­mo­wych pro­ce­sów (poje­dyn­czych czyn­no­ści) na ele­men­tar­ne usłu­gi apli­ka­cyj­ne. Usługi te, to nic inne­go jak przy­pad­ki uży­cia apli­ka­cji, czy­li każ­dą apli­ka­cję (jej uży­tecz­ność) moż­na opi­sać z pomo­cą jej przy­pad­ków uży­cia”, a te jak już wie­my, w UML słu­żą – jak widać słusz­nie – do spe­cy­fi­ko­wa­nia wyma­gań funk­cjo­nal­nych. Tu uwa­ga, nie nale­ży tego mylić ze spo­ty­ka­ny­mi w lite­ra­tu­rze biz­ne­so­wy­mi przy­pad­ka­mi uży­cia” (nie ma taki w UML).

Konwencja biz­ne­so­wych przy­pad­ków uży­cia to relikt meto­dy RUP z lat 90’tych, kie­dy to nie było np. nota­cji BPMN, i tak zwa­ny biz­ne­so­wy dia­gram przy­pad­ków uży­cia” opi­sy­wał fir­mę, jej usłu­gi i klien­tów (akto­rów), a nie apli­ka­cję (do dzi­siaj jest to przy­czy­ną wie­lu nie­po­ro­zu­mień i powsta­wa­nia niskiej jako­ści nie­jed­no­znacz­nych dokumentacji). 

Tak więc, jak widać, moż­na uznać (przy­jąć), że przy­pa­dek uży­cia to usłu­ga apli­ka­cji, a ich gra­da­cję okre­śla pro­dukt jako uży­tecz­ność efek­tu. Co cie­ka­we, nie­któ­re narzę­dzia CASE wspie­ra­ją (uła­twia­ją) two­rze­nie (mapo­wa­nie) czyn­no­ści (ele­men­tar­nych pro­ce­sów biz­ne­so­wych) w pro­ce­sach (nota­cja BPMN) na przy­pad­ki uży­cia (nota­cja UML).

Taksonomia wyma­gań, w tym biz­ne­so­we i przy­pad­ki uży­cia oraz usłu­gi apli­ka­cyj­ne (Produkty w pro­ce­sie ana­li­zy wyma­gań):

Wymagania

Warto tu teraz zwró­cić uwa­gę, że wyma­ga­nia funk­cjo­nal­ne i poza-funk­cjo­nal­ne, jako­ścio­we i dzie­dzi­no­we oraz usłu­gi sys­te­mu to ele­men­ty abstrakcyjne.

Tak na praw­dę rze­czy­wi­ste są jedy­nie wyma­ga­nia biz­ne­so­we jako ocze­ki­wa­nia zama­wia­ją­ce­go wyra­żo­ne w jego języ­ku, oraz przy­pad­ki uży­cia i model dzie­dzi­ny, bo opi­su­ją rze­czy­wi­sty byt jakim jest (przy­szły) pro­dukt (apli­ka­cja).

CRUD, czym jest?

CRUD to skrót od ang. Create, Retrieve, Update, Delete (Utwórz, Przywołaj, Zaktualizuj, Usuń). Są to czte­ry pod­sta­wo­we ope­ra­cje na tak zwa­nych kar­to­te­kach, obiek­tach słu­żą­cych do zapa­mię­ty­wa­nia infor­ma­cji czy­li poje­dyn­czych encji” (nie mylić z encja­mi w bazach rela­cyj­nych) lub ich agre­ga­tach. Obiektami odpo­wie­dzial­nym za ich prze­cho­wy­wa­nie są repo­zy­to­ria (Repository). Kluczowe czte­ry ope­ra­cje udo­stęp­nia­ne przez repo­zy­to­rium to wła­śnie CRUD. Pytanie brzmi: czym jest kar­to­te­ka? Jest zbio­rem kart (doku­men­tów) o jed­na­ko­wej (lub podob­nej) struk­tu­rze. Tak więc usłu­gą jest zarzą­dza­nie kar­ta­mi”, czy też odręb­ny­mi usłu­ga­mi są two­rze­nie kar­ty, czy­ta­nie, uzu­peł­nie­nie, usu­nię­cie? Popatrzmy na to z per­spek­ty­wy usłu­gi dla użyt­kow­ni­ka: ma sens posia­da­nie wygod­nej szu­fla­dy z kar­ta­mi w biblio­te­ce ale czy ma sens samo­dziel­na, wyję­ta z kon­tek­stu usłu­ga two­rze­nie nowych kart”? Można pole­mi­zo­wać, ale jeże­li chcieć utrzy­mać spój­ność poję­cio­wą i moż­li­wość kon­tro­li spój­no­ści i kom­plet­no­ści pro­jek­tu i jego zakre­su, lepiej uznać, że usłu­gą apli­ka­cyj­ną jest zarzą­dza­nie kar­ta­mi”. Po pierw­sze taka usłu­ga jest samo­wy­star­czal­na, zaś samo two­rze­nie kar­ty bez moż­li­wo­ści jej przy­wo­ła­nia nie ma sen­su, więc te czte­ry pro­ste czyn­no­ści są nie­ja­ko nie­ro­ze­rwal­nie zwią­za­ne, sta­no­wiąc jed­ną usłu­gę. Po dru­gie two­rze­nie nowe­go zapi­su, mody­fi­ko­wa­nie czy usu­wa­nie, to kon­tekst użyt­kow­ni­ka, w zasa­dzie każ­dą z czte­rech ope­ra­cji CRUD moż­na spro­wa­dzić do scenariusza:

  1. pokaż kar­tę (pusta to two­rze­nie nowe­go zapisu)
  2. zrób z tym coś (wpisz nowe, zmień, usuń) i potwierdź (zacho­waj skutek)

Dlatego są pod­sta­wy by uznać, że zarzą­dza­nie kar­ta­mi kata­lo­go­wy­mi” to jed­nak jeden przy­pa­dek uży­cia, a poszcze­gól­ne ope­ra­cje, to kon­tek­sto­we warian­ty sce­na­riu­sza wyni­ka­ją­ce z pro­ce­su czy­li chwi­lo­we­go celu użyt­kow­ni­ka (akto­ra). To podob­nie jak mło­tek (usłu­ga dostęp­na ze skrzyn­ki narzę­dzio­wej), to czło­wiek uży­wa młot­ka w kon­tek­ście wbi­ja­nie gwoź­dzia, zbi­ja­nia szy­by, roz­bi­ja­nia kamie­ni. Młotek w rękach czło­wie­ka po pro­stu słu­ży do ude­rza­nia, więc przy­pad­kiem uży­cia jest ude­rza­nie a nie czyn­ność w pro­ce­sie zbi­ja­nia budy dla psa jaką jest wbi­ja­nie gwoź­dzi w deski. Podejście takie wca­le nie jest nowe, w cie­ka­wy spo­sób opi­sał to autor tego artykułu:

If you have ever been wri­ting use cases for a data-orien­ted sys­tem (i.e. CMS), you have pro­ba­bly noti­ced that the­re is a pro­blem with the lar­ge num­ber of use cases like Add an artic­le”, Remove an artic­le” etc. If you have all CRUD ope­ra­tions ava­ila­ble for all objects in the sys­tem, you can finish with up to 4 x num­ber-of-objects of use cases. You can redu­ce this num­ber by intro­du­cing the CRUD pat­tern, which I would like to pre­sent you in this blog entry. (CRUD Pattern in Use Cases ? PUT Software Engineering Team).

Można takie podej­ście (wyni­ka­ją­ce nie­ja­ko wprost z defi­ni­cji przy­to­czo­nych pojęć), jak widać, nazwać wzor­cem pro­jek­to­wym :). Bardzo ład­nie prze­kła­da się to na archi­tek­tu­rę (model opar­ty o wzo­rzec BCE), ope­ru­ją­cą poję­cia­mi boun­da­ry (gra­ni­ca), con­troll ( ste­ro­wa­nie) i enti­ty (nośnik informacji):

Wzorzec BCE

Na powyż­szym dia­gra­mie mamy dwa przy­pad­ki uży­cia: gór­ny to typo­wy CRUD, dol­ny do usłu­ga, np. obli­cze­nio­wa. Przypadek pierw­szy (gór­ny) dodat­ko­wo korzy­sta z logi­ki Samodzielna logi­ka” tego dru­gie­go PU (inte­gra­cja dwóch aplikacji/komponentów).

Poniżej dwa cie­ka­we arty­ku­ły, roz­wi­ja­ją­ce powyż­sze. Pierwszy to tak zwa­ne mikro ser­wi­sy, wzo­rzec trak­tu­ją­cy każ­dą usłu­gę apli­ka­cyj­ną 9a tym samym przy­pa­dek uży­cia) jako odręb­ną apli­ka­cję, dru­gi poka­zu­je jak pro­jek­to­wać inter­fej­sy w takich przypadkach.

Microservices” – yet ano­ther new term on the crow­ded stre­ets of softwa­re archi­tec­tu­re. Although our natu­ral inc­li­na­tion is to pass such things by with a con­temp­tu­ous glan­ce, this bit of ter­mi­no­lo­gy descri­bes a sty­le of softwa­re sys­tems that we are fin­ding more and more appe­aling. We’ve seen many pro­jects use this sty­le in the last few years, and results so far have been posi­ti­ve, so much so that for many of our col­le­agu­es this is beco­ming the default sty­le for buil­ding enter­pri­se appli­ca­tions. Sadly, howe­ver, the­re­’s not much infor­ma­tion that outli­nes what the micro­se­rvi­ce sty­le is and how to do it. (Microservices).

Tell-Don’t-Ask is a prin­ci­ple that helps people remem­ber that object-orien­ta­tion is abo­ut bun­dling data with the func­tions that ope­ra­te on that data. It reminds us that rather than asking an object for data and acting on that data, we sho­uld inste­ad tell an object what to do. This enco­ura­ges to move beha­vior into an object to go with the data. (TellDontAsk).

Na zakończenie

Analizy biz­ne­so­we wyma­ga­ją ode­rwa­nia się od tech­no­kra­cji, nie ma cze­goś takie­go jak dzie­siąt­ki przy­pad­ków uży­cia dla jed­nej fak­tu­ry, nie ma sys­te­mo­wych przy­pad­ków uży­cia (nawet w spe­cy­fi­ka­cji UML ich nie znaj­dzie­cie), są kom­plet­ne (dają­ce jako efekt przy­dat­ne pro­duk­ty) usłu­gi apli­ka­cyj­ne i korzy­sta­ją­cy z tych usług akto­rzy, w tym inne apli­ka­cje lub kom­po­nen­ty. Dokumentacje zawie­ra­ją­ce set­ki przy­pad­ków uży­cia to nie­po­ro­zu­mie­nie, tech­no­kra­tycz­ni zabój­cy pro­jek­tów. Warto się zasta­no­wić zanim powie­rzy­cie ana­li­zę i pro­jekt logi­ki sys­te­mu tech­no­kra­tycz­ne­mu deve­lo­pe­ro­wi… Zapraszam do lek­tu­ry kolej­ne­go arty­ku­łu o zarzą­dza­niu szcze­gó­ło­wo­ścią ana­li­zy..

Communication with words isn?t always bridging the gap, komunikacja werbalna nie zawsze wypełni lukę komunikacyjną, luka komunikacyjna

Inżynieria wymagań

Wczoraj odby­ła się w Warszawie kon­fe­ren­cja Inżynieria Wymagań, na któ­rej mia­łem przy­jem­ność wygło­sić refe­rat o kla­sy­fi­ka­cji wyma­gań. Celem mojej pre­zen­ta­cji było zwró­ce­nie uwa­gi na to, że zarzą­dza­nie wyma­ga­nia­mi to nie tyl­ko ich zbie­ra­nie i kla­sy­fi­ko­wa­nie” oraz, że wyma­gań jest wię­cej niż tyl­ko funk­cjo­nal­ne i poza-funkcjonalne”.

Powszechny w lite­ra­tu­rze przed­mio­tu ter­min pozy­ski­wa­nie wyma­gań” jest bar­dzo róż­nie rozu­mia­ny. Można wyma­ga­nia pozy­ski­wać” pod­czas sesji warsz­ta­to­wych JAD, burz mózgów, z pomo­cą ankiet, pisa­nia user sto­ry” itp. Wszystkie te meto­dy mają jed­ną poważ­ną wadę: pro­du­ku­ją ogrom­ną ilość dekla­ra­tyw­nych, nie­we­ry­fi­ko­wal­nych tre­ści. Lista wyma­gań w posta­ci tabe­li z set­ka­mi wier­szy niko­go tu nie zaska­ku­je. To nie działa!

Inżynieria wymagań

Coraz czę­ściej zaczy­na poja­wiać się poja­wiać nie tyl­ko w pra­sie, poję­cie inży­nie­ria wyma­gań”. Dla zasa­dy popa­trz­my na zna­cze­nia słów (sł. j. polskiego):

inży­nie­ria ?pro­jek­to­wa­nie i kon­stru­owa­nie obiek­tów oraz urzą­dzeń technicznych?
wyma­ga­nie ?waru­nek lub zespół warun­ków, któ­rym ktoś lub coś musi odpowiadać?
wyma­ga­ny ?nie­zbęd­nie potrzebny?

Tak więc inży­nie­ria wyma­gań to pro­jek­to­wa­nie nie­zbęd­nych warun­ków, któ­rym coś [roz­wią­za­nie] musi odpo­wia­dać”. Moim zda­niem istot­ne jest jest uży­cie sło­wa pro­jek­to­wa­nie” a nie zbie­ra­nie”. Zbieranie to pra­ca ste­no­gra­fa. Projektowanie to już zupeł­nie inna pra­ca. Raz, że twór­cza, dwa że rzą­dzą­ca się pew­ny­mi pra­wa­mi: przede wszyst­kim spe­cy­fi­ka­cja wyma­gań to pew­na okre­ślo­na kon­struk­cja. Jaka? Zgodnie z zasa­da­mi: spój­na, nie­sprzecz­na, wery­fi­ko­wal­na i kom­plet­na. Czy takie cechy ma np. ste­no­gram z kil­ku­dnio­wych warsz­ta­tów JAD czy burzy mózgów albo dane zebra­ne z ankiet wśród przy­szłych użyt­kow­ni­ków dane­go roz­wią­za­nia? Szczerze wąt­pię.

Pojawia się kolej­ne pyta­nie: co z wyni­ka­mi ana­li­zy wyma­gań po zakoń­cze­niu pro­jek­tu wdro­że­nio­we­go? Niemalże w 100% przy­pad­ków są odkła­da­ne na pół­kę, a kolej­ne wdro­że­nie lub roz­bu­do­wa posia­da­nych narzę­dzi, to kolej­na, pro­wa­dzo­na od zera ana­li­za wyma­gań. Jak słusz­nie zauwa­żył jeden z pre­le­gen­tów, wyłą­cza­jąc start-up’y, pro­jek­ty wdro­że­nio­we (wybór, zakup, imple­men­ta­cja) to tak na praw­dę zarzą­dza­nie zmia­ną a nie nowe projekty”.

Wyobraźmy sobie, że zamiast odkła­dać doku­men­ta­cję wyma­gań do lamu­sa, utrzy­mu­je­my jej aktu­al­ność i wycią­ga­my ją za każ­dym razem, gdy roz­po­czy­na­my kolej­ny nowy pro­jekt, wyma­ga­ją­cy zmia­ny jakiejś funk­cjo­nal­no­ści lub pozy­ska­nia cał­kiem nowej. Wtedy, zamiast pro­wa­dzić kolej­ną kosz­tow­ną i dłu­gą ana­li­zę wyma­gań, ana­li­zu­je­my pla­no­wa­ne zmia­ny i nano­si­my je na posia­da­ną już i kon­ser­wo­wa­ną doku­men­ta­cję. Próby korzy­sta­nia z ana­liz poprzed­nich ad-hoc naj­czę­ściej koń­czą się fia­skiem, gdyż z regu­ły każ­dą robi inny dostaw­ca roz­wią­za­nia, więc każ­da jest inna i naj­czę­ściej nie­spój­na z innymi.

Spójrzmy teraz na poniż­szy diagram:

architektura korporacyjna rentowność

Na dia­gra­mie mamy dwie linie (linia prze­ry­wa­na to kosz­ty bie­żą­ce, cią­gła to kosz­ty nara­sta­ją­co): czer­wo­na to kosz­ty tra­dy­cyj­ne­go mode­lu pro­wa­dze­nia nie­za­leż­nych ana­liz, od zera” dla każ­de­go pro­jek­tu. Niebieska poka­zu­je kosz­ty mode­lu, w któ­rym zarzą­dza­my zmia­ną. Realia poka­zu­ją, że oszczęd­no­ści są jesz­cze więk­sze, gdyż w mode­lu ana­liz ad-hoc, pomniej­sze pro­jek­ty reali­zo­wa­ne są zwin­nie” bez żad­nej doku­men­ta­cji, gdyż albo nie ma na jej opra­co­wa­nie cza­su (bar­dzo czę­sto) albo wiel­kość (mały) pro­jek­tu skła­nia do podej­mo­wa­nia ryzy­ka pra­cy bez doku­men­ta­cji. Niestety pra­ca bez doku­men­ta­cji czę­sto pro­wa­dzi do odkry­wa­nia wyma­gań dość kosz­tow­ną meto­dą prób i błę­dów (pro­to­ty­po­wa­nie). Jak wie­my, pra­wie 80% pro­jek­tów to pro­jek­ty wadli­we, w 100% przy­pad­ków źró­dłem jest (mię­dzy inny­mi) zła spe­cy­fi­ka­cja wymagań.

Jak widać, z zupeł­nie z innej stro­ny odkry­li­śmy” coś co nazy­wa­my archi­tek­tu­rą kor­po­ra­cyj­ną. Skoro każ­da ana­li­za wyma­gań w ist­nie­ją­cej orga­ni­za­cji, to każ­do­ra­zo­wa ana­li­za od pozio­mu moty­wa­cji biz­ne­so­wej pro­jek­tu, przez wyma­ga­ne usłu­gi apli­ka­cyj­ne, inte­gra­cje aż do plat­form sprzę­to­wo-sys­te­mo­wych, to mamy nic inne­go, jak pro­jekt doku­men­to­wa­nia archi­tek­tu­ry kor­po­ra­cyj­nej. I na koniec bar­dzo waż­na moja uwa­ga: za jakość wyma­gań odpo­wia­da i pono­si kon­se­kwen­cje w 100% kupu­ją­cy, nigdy dostawca!

Ma sens? Ma!

Na koniec pole­cam bar­dzo cie­ka­wy arty­kuł Bogdana Berezy o inży­nie­rii opro­gra­mo­wa­nia w dzi­siej­szym (19 Marca 2014) nume­rze [[COMPUTERWORLD]].

Inżynieria wymagań

W grud­niu 2011 roku napi­sa­łem na zakoń­cze­nie pew­ne­go arty­ku­łu o wymaganiach:

Większość pro­jek­tów takich jak np. wdra­ża­nie nowych metod kon­tro­lin­gu, zrów­no­wa­żo­nej kar­ty wyni­ków, nowych sys­te­mów IT itp. cier­pi głów­nie z powo­du posia­da­nia nad­mia­ru infor­ma­cji z jed­nej stro­ny i kom­plet­ne­go jej nie­zro­zu­mie­nia z dru­giej. Sławne już w bada­niach ?złe i nie­kom­plet­ne wyma­ga­nia? czy ?zmia­ny zakre­su pro­jek­tu w trak­cie jego trwa­nia? to kla­sycz­ne skut­ki złej (a czę­sto pomi­ja­nia!) ana­li­zy biz­ne­so­wej. Koszty tych pora­żek wie­lo­krot­nie prze­wyż­sza­ją koszt takich ana­liz. (Analiza biz­ne­so­wa ? sku­tecz­ne mode­lo­wa­nie a ryzy­ko pro­jek­tu).

Specyfikowanie wyma­gań, zarzą­dza­nie wyma­ga­nia­mi, inży­nie­ria wyma­gań, to jak widać bar­dzo trud­ny etap pro­jek­tu. Trudność bie­rze się stad, że dostęp­ne zale­ce­nia okre­śla­ją, że wyma­ga­nia maja być np. spój­ne i kom­plet­ne ale zupeł­nie nie opi­su­ją jak to osią­gnąć (a nawet jak to spraw­dzić).

Często moż­na się spo­tkać z poję­ciem inży­nie­ria wyma­gań”. Budzi ono mój opór z dwóch powo­dów: zna­cze­nie sło­wa inży­nie­ria w j.polskim i nie­ade­kwat­ność tego sło­wa do dzie­dzi­ny jaką jest spe­cy­fi­ko­wa­nie wyma­gań, któ­re są po pro­tu listą warunków.

Zajrzyjmy do słow­ni­ka języ­ka polskiego:

inży­nie­ria ?pro­jek­to­wa­nie i kon­stru­owa­nie obiek­tów oraz urzą­dzeń technicznych?

wyma­ga­nie ?waru­nek lub zespół warun­ków, któ­rym ktoś lub coś musi odpowiadać?

Więc jak rozu­mieć zło­że­nie inży­nie­ria wyma­gań”? Ja nie wiem, chy­ba, że ktoś uwa­ża, że wyma­ga­nia się kon­stru­uje”, i że są to zagad­nie­nia tech­nicz­ne. Za to ma sens inży­nie­rii sys­te­mów”. Mamy def. poję­cia system:

sys­tem ?układ ele­men­tów mają­cy okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?

Gdyby defi­ni­cje sło­wa inży­nie­ria” okro­ić z tech­nicz­nych” albo uznać, że sys­te­my są tak­że nie tech­nicz­ne (bo są np. spo­łecz­ne) to mamy wdzięcz­na definicję:

inży­nie­ria sys­te­mów ?pro­jek­to­wa­nie i kon­stru­owa­nie ukła­dów ele­men­tów mają­cych okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?

Jeden z moich ulu­bio­nych auto­rów aka­de­mic­kich, Ian Sommeville (lubię go tak­że za to, że książ­ki pisze w pubach popi­ja­jąc piwo ;)) defi­niu­je inży­nie­rię wyma­gań tak:

Requirements engi­ne­ering (RE) refers to the pro­cess of for­mu­la­ting, docu­men­ting and main­ta­ining softwa­re requ­ire­ments (źr. Kotonya G. and Sommerville, I. Requirements Engineering: Processes and Techniques. Chichester, UK: John Wiley & Sons)

(poję­cie inży­nie­rii wyma­gań odno­si do pro­ce­su for­mu­ło­wa­nia, doku­men­to­wa­nia i zarzą­dza­nia wymaganiami)

Tak więc uzna­jąc, że wyma­ga­nia na sys­te­my to ele­ment inży­nie­rii tych sys­te­mów, niniej­szym godzę się uży­wać poję­cia inży­nie­ria wyma­gań” w zna­cze­niu jakim opi­sał to Sommerville :).

Po co tyle glę­dze­nia o sło­wach i ich zna­cze­niach? Poza szu­ka­niem” ali­bi dla ist­nie­nia poję­cia inży­nie­ra wyma­gań” chcę poka­zać, że sło­wa mają zna­cze­nie, zanie­dby­wa­nie tego pro­wa­dzi do wie­lu nie­po­ro­zu­mień (nie­jed­no­znacz­ność) a po dru­gie zwra­cam uwa­gę, że ana­li­za poję­cio­wa to jeden z klu­czo­wych ele­men­tów ana­li­zy w ogó­le (i czę­sto zaniedbywana).

Skoro wyma­ga­nia to warun­ki, to aż pro­si się by te warun­ki spraw­dzać. Patrzmy do słownika:

spraw­dzać ?skon­tro­lo­wać, zba­dać, czy coś jest zgod­ne z praw­dą, czy coś zosta­ło zro­bio­ne prawidłowo?

Tak więc wnio­sek jest pro­sty: wyma­ga­nie (każ­de!) powin­no być spraw­dzal­ne! Bez tego nie jeste­śmy w sta­nie okre­ślić czy coś” speł­nia te wyma­ga­nia, czy­li czy zda­nie: dostar­czo­ny pro­dukt jest zgod­ny z wyma­ga­nia­mi” jest praw­dzi­we czy nie (a nie chce­my oddać roz­strzy­ga­nia tego prawnikom ;)).

Inżynieria wymagań

Skoro więc ugią­łem się i uzna­łem poję­cie inży­nie­rii wyma­gań, popa­trz­my na to sys­te­mo­wo. Jak zawsze pro­ste jest pięk­ne więc co ana­li­zu­je­my w inży­nie­rii sys­te­mo­wej i inży­nie­rii wymagań:

Granice systemu

matrioszkaPojęcie sys­tem” to tak­że super­sys­tem (sys­tem nad­rzęd­ny) i pod­sys­tem (sys­tem pod­rzęd­ny, część sys­te­mu). To trosz­kę jak zna­ne wam, być może, matriosz­ki 🙂 (figur­ki jed­na w drugiej…).

Jest to, nazew­nic­two, bar­dzo waż­ne, bo w jed­nym pro­jek­cie (doku­men­ta­cji) nale­ży zacho­wać bez­względ­ną dys­cy­pli­nę poję­cio­wą, czy­li sło­wo System powin­no się odno­sić wyłącz­nie do kon­kret­ne­go pozio­mu opi­su, resz­ta to ele­men­ty sys­te­mu nad­rzęd­ne­go lub podrzędnego.

Mianem sys­tem okre­śla się zwy­cza­jo­wo spe­cy­fi­ko­wa­ne opro­gra­mo­wa­nie, jed­nak pro­blem poja­wi się natych­miast, gdy dotknie­my takich pojęć jak wyma­ga­nia funk­cjo­nal­ne na opro­gra­mo­wa­nie i wyma­ga­nia biz­ne­so­we. To ostat­nie nie­sie pew­ną nie­ja­sność. Bo nie wiem czy cho­dzi o wyma­ga­nia wobec (w sto­sun­ku do) biz­ne­su (np. popra­wa jako­ści obsłu­gi klien­ta o 5% w naj­bliż­szym bada­niu jako­ści ISO) czy wyma­ga­nia biz­ne­su wobec (w sto­sun­ku do) opro­gra­mo­wa­nia (np. mini­ma­li­za­cja do zera otrzy­ma­nych i zagu­bio­nych zapy­tań ofertowych).

Popatrzmy na powyż­szy dia­gram. Mamy tu dwa Systemy:

  1. Organizacja jest pod­sys­te­mem, jest ele­men­tem sys­te­mu, któ­rym tu jest rynek na jakim ta orga­ni­za­cja funkcjonuje.
  2. Organizacja jest ana­li­zo­wa­nym sys­te­mem, opro­gra­mo­wa­nie jest jed­nym z zaso­bów tej orga­ni­za­cji (opro­gra­mo­wa­nie jest tu podsystemem).

Wymagania może­my tu odno­sić w sto­sun­ku do Organizacji i w sto­sun­ku do Oprogramowania. To dla­te­go jasno wyod­ręb­nia­my ana­li­zę biz­ne­so­wą (pro­duk­tem są mode­le biz­ne­so­we i wyma­ga­nia biz­ne­so­we) od ana­li­zy wyma­gań na opro­gra­mo­wa­nie (mode­le i wyma­ga­nia na opro­gra­mo­wa­nie). Jak widać wyma­ga­nia na opro­gra­mo­wa­nie to wyma­ga­nia, któ­rych źró­dłem jest biz­nes, któ­ry ma kon­kret­ne cele do osią­gnię­cia. Nie powin­ny być one poboż­ny­mi życze­nia­mi użyt­kow­ni­ków, aż do momen­tu gdy spon­sor pro­jek­tu nie powie np.: moim celem jest wygo­da pra­cy moich pra­cow­ni­ków. Oczywiście, ta wygo­da jest zawsze wyma­ga­na ale nie musi ona być celem samym w sobie i nie musi mieć naj­wyż­sze­go priorytetu.

Wymagania inte­re­sa­riu­szy. Moja defi­ni­cja inte­re­sa­riu­sza (jed­na z wie­lu): oso­ba (pod­miot) zain­te­re­so­wa­na zaist­nie­niem pro­duk­tu, na któ­rą poja­wie­nie się pro­duk­tu ma wpływ. Nie raz jestem pyta­ny czy inte­re­sa­riusz ma pra­wo zgła­sza­nia wyma­gań. Jeżeli ma coś do powie­dze­nia pod­czas odbio­ru pro­duk­tu to zna­czy, że ma wyma­ga­nia. One mogą być jed­nak nie­jaw­ne czy­li taki inte­re­sa­riusz nie zgła­sza wyma­gań ale ma wpływ na odbiór pro­duk­tu, nale­ży go koniecz­nie ziden­ty­fi­ko­wać. Jeżeli zaś ktoś nie ma nic do gada­nia przy odbio­rze pro­duk­tu nie jest inte­re­sa­riu­szem (ang. sta­ke­hol­der, klu­czem jest tu «hol­der» czy­li dys­po­nent mają­cy coś do powie­dze­nia, mają­cy wpływ). Tak wiec inte­re­sa­riusz to ktoś kto, na swo­im pozio­mie ogól­no­ści, tak­że musi umieć okre­ślić, kie­dy uzna, że pro­dukt speł­nia jego wyma­ga­nia. Jak nie potra­fi, ktoś musi mu pomóc…analityk :)).

I tu rola ana­li­ty­ka. Interesariusz spi­su­je co mu przyj­dzie do gło­wy swo­im języ­kiem, ana­li­tyk upew­nia się, że zro­zu­miał, dopro­wa­dza je do posta­ci testo­wal­nej i kla­sy­fi­ku­je wyma­ga­nia” jako źró­dło: kon­kret­ny inte­re­sa­riusz” (bo każ­de wyma­ga­nie musi mieć wła­ści­cie­la). Proszę zwró­cić uwa­gę, że inte­re­sa­riu­szem jest tak­że użyt­kow­nik jeże­li tyl­ko ma coś go powie­dze­nia w projekcie :).

Popatrzmy na wymaganie:

Wymagania

Wymaganie jest jed­no (waru­nek jaki coś musi speł­nić) ale może ono mieć wie­le atry­bu­tów i tu widzę zło­żo­ność” wyma­gań (ich [[tak­so­no­mia]]). Zarówno wysta­wia­nie fak­tur VAT” jak i dostęp­ność 99,99% cza­su” to rów­no­praw­ne wyma­ga­nia bo opro­gra­mo­wa­nie np. wspo­ma­ga­ją­ce sprze­daż jest bez­war­to­ścio­we zarów­no gdy nie pozwa­la wysta­wiać fak­tur jak wte­dy, gdy czę­sto się psu­je. Owszem, jed­no jest funk­cjo­nal­ne dru­gie jest poza-funk­cjo­nal­ne ale jed­no i dru­gie to rów­no­praw­ny waru­nek przy­dat­no­ści” czy­li Wymaganie wobec oprogramowania.

Jak wspo­mnia­łem, wyma­ga­nia są (war­to tak robić) kla­sy­fi­ko­wa­ne za pomo­cą atry­bu­tów. Najczęściej spo­ty­ka­ne to: rodzaj (Kind), źró­dło wyma­ga­nia (Source), pole­cam tak­że prio­ry­tet, meto­dę wery­fi­ka­cji (np. test, audyt zgod­no­ści z opi­sem w doku­men­ta­cji), sta­tus (pla­no­wa­ne, zaakc­pe­to­wa­ne, odrzu­co­ne, …) i inne, zależ­nie od wyma­gań i typu projektu.

Ważna uwa­ga i zale­ce­nie IIBA: zarzą­dza­nie wyma­ga­nia­mi zabra­nia” ich usu­wa­nia (albo renu­me­ra­cji po usu­nię­ciu). usu­wa­nie powo­du­je to nie­spój­ność wer­sjo­no­wa­nej doku­men­ta­cji, któ­ra tak­że ma swój cykl życia. Ja od dłuż­sze­go cza­su sto­su­ję dodat­ko­wy sta­tus odrzu­co­ne”, co daje mi cią­głość doku­men­ta­cji a tak­że pozwa­la na odwie­sze­nie” wcze­śniej zde­fi­nio­wa­ne­go wyma­ga­nia, gdy ktoś jed­nak uzna, że coś co było zbęd­ne nagle zno­wu sta­je się konieczne :).

Liczba pytań i suge­stii (tak­że na kil­ku forach dys­ku­syj­na) skło­ni­ła mnie do pod­ję­cia pró­by zbu­do­wa­nia tak­so­no­mii wyma­gań. Jak już wspo­mnia­łem wyżej, zale­ce­nia takie jak FURPS to nie­ste­ty tyl­ko pła­ska lista cech” (i nie wszyst­kich). Wydaje mi się, że struk­tu­ra wyma­gań, ich tak­so­no­mia wza­jem­ne zależ­no­ści oraz rela­cje do udzia­łow­ców pro­jek­tu (inte­re­sa­riu­sze) i przy­szłych użyt­kow­ni­ków roz­wią­za­nia, wyma­ga­ją bar­dziej for­mal­ne­go podej­ścia. Celem jest uzy­ska­nie moż­li­wo­ści spraw­dza­nia czy wyma­ga­nia – jako przed­miot inży­nie­rii wyma­gań – speł­nia­ją jakieś, trze­ba je stwo­rzyć, wymagania.

Taksonomia wymaganPowyżej pró­ba usys­te­ma­ty­zo­wa­nia wyma­gań” na bazie wyżej cyto­wa­nych defi­ni­cji tego pojęcia.

Na koniec jesz­cze kolej­na waż­na rzecz. Warto wska­zy­wać, któ­re ele­men­ty logi­ki biz­ne­so­wej (Model) odpo­wia­da­ją (są powią­za­ne) z danym wyma­ga­niem bo np. szcze­gó­ło­wo opi­su­ją wyma­ga­ny spo­sób reali­za­cji dane­go wyma­ga­nia (np. sys­tem upu­stów albo kon­kret­ny przy­pa­dek uży­cia, tak­że Model). Warto tak­że, jeże­li opis wyma­ga­nia nie jest testem, zapro­jek­to­wać test (przy­pa­dek testo­wy), któ­ry potwier­dzi speł­nie­nie wyma­ga­nia np. opro­gra­mo­wa­nie ma pozwa­lać na wyli­cza­nie pier­wiast­ków dru­gie­go i trze­cie­go stop­nia”. Tu war­to podać kil­ka kon­kret­nych danych wej­ścio­wych wraz z pra­wi­dło­wy­mi wyni­ka­mi (może to doty­czyć nap. tabe­li upu­stów, sys­te­mu sko­rin­gu klien­tów itp.).

Tego typu meto­dy maja nazwę deklaratywnych:

Programowanie dekla­ra­tyw­ne ? rodzi­na para­dyg­ma­tów pro­gra­mo­wa­nia, któ­re nie są z natu­ry impe­ra­tyw­ne. W prze­ci­wień­stwie do pro­gra­mów napi­sa­nych impe­ra­tyw­nie, pro­gra­mi­sta opi­su­je warun­ki, jakie musi speł­niać koń­co­we roz­wią­za­nie (co chce­my osią­gnąć), a nie szcze­gó­ło­wą sekwen­cję kro­ków, któ­re do nie­go pro­wa­dzą (jak to zro­bić). Programowanie dekla­ra­tyw­ne czę­sto trak­tu­je pro­gra­my jako pew­ne hipo­te­zy wyra­żo­ne w logi­ce for­mal­nej, a wyko­ny­wa­nie obli­czeń jako ich dowo­dze­nie. Programowanie dekla­ra­tyw­ne jest szcze­gól­nym przed­mio­tem zain­te­re­so­wa­nia naukow­ców, gdyż dzię­ki mini­ma­li­za­cji lub eli­mi­na­cji skut­ków ubocz­nych może zna­czą­co upro­ścić two­rze­nie pro­gra­mów współ­bież­nych. Paradygmat pro­gra­mo­wa­nia dekla­ra­tyw­ne­go obej­mu­je sze­ro­ką gamę języ­ków pro­gra­mo­wa­nia i bar­dziej szcze­gó­ło­wych para­dyg­ma­tów pod­rzęd­nych. (Programowanie dekla­ra­tyw­ne ? Wikipedia, wol­na ency­klo­pe­dia).

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ć…

Dokumentowanie wymagań na systemy nie tylko ERP – droga do porażki

Wśród wie­lu zna­nych i sto­so­wa­nych spo­so­bów doku­men­to­wa­nia wyma­gań na sys­te­my są tek­sto­we i tabe­la­rycz­ne opi­sy oraz meto­dy for­mal­ne. Pierwsze są tak nie­jed­no­znacz­ne, że są źró­dłem wie­lu pro­ble­mów dru­gie tak kosz­tow­ne i nie­zro­zu­mia­łe dla laików”, że w zasa­dzie nie sto­so­wa­ne. Pośrodku mamy meto­dy pół­for­mal­ne” czy­li mode­le. Ich cechą jest duża jed­no­znacz­ność wyma­ga­ją jed­nak pew­ne­go mini­mal­ne­go oby­cia z dia­gra­ma­mi u ich czy­tel­ni­ka oraz dużych umie­jęt­no­ści u twór­cy. czę­sto powta­rzam swo­im stu­den­tom: dobry model jest jak wiersz: dużą sztu­ką jest jego napi­sa­nie ale do prze­czy­ta­nia powin­na wystar­czyć zna­jo­mość alfa­be­tu. W tym arty­ku­le, adre­so­wa­nym do każ­de­go kto spo­ty­ka się lub wie, że go to spo­tka, z ana­li­za­mi wyma­gań i ich doku­men­to­wa­niem za pomo­cą dia­gra­mów. Zwrócę tak­że uwa­gę na typo­we pro­ble­my i ryzy­ka zwią­za­ne ze sto­so­wa­niem popu­lar­nych meto­dyk i notacji.

Napisze kil­ka słów adre­so­wa­nych głów­nie do nabyw­ców sys­te­mów. Powiem na co zwra­cać uwa­gę w doku­men­ta­cjach wyma­gań i cze­go raczej nie robić same­mu. Cała doku­men­ta­cja wyma­gań opi­su­je to jaki ma być przy­szłe opro­gra­mo­wa­nie jed­nak klu­czem do jej sku­tecz­no­ści jest opis biz­ne­so­wy orga­ni­za­cji i jej zro­zu­mie­nie czy­li zro­zu­mia­ły dla wszyst­kich uczest­ni­ków pro­jek­tu model biz­ne­so­wy i wska­za­ny na nim zakres pro­jek­tu. Jest to naj­czę­ściej pomi­ja­ny ele­ment pro­jek­tu przez dostaw­ców sys­te­mów. Dlaczego? Zaryzykuje tezę: dostaw­cy sys­te­mów to dobrzy inży­nie­ro­wie, któ­rzy z regu­ły nie mają wie­dzy i doświad­cze­nia z zakre­su mar­ke­tin­gu i zarzą­dza­nia jed­nak anga­żo­wa­ni są w two­rze­nie narzę­dzi do wspo­ma­ga­nia zarzą­dza­nia. Źródłem wie­lu pro­ble­mów pro­jek­tów IT jest luka komu­ni­ka­cyj­na pomię­dzy biz­ne­sem a inży­nie­rią opro­gra­mo­wa­nia. Podobno powszech­nie o tym wia­do­mo a jed­nak nadal wie­le doku­men­ta­cji wyma­gań pozo­sta­wia wie­le do życze­nia. Dlaczego?

O tym jak przy­pad­ki uży­cia rodzą kłopoty

Obserwuję dwa rodza­je róż­nych podejść do ana­li­zy i doku­men­to­wa­nia wyma­gań: opi­sy testo­we i struk­tu­ral­ne w przy­pad­ku pla­no­wa­ne­go zaku­pu goto­we­go sys­te­mu oraz meto­dy zorien­to­wa­ne na przy­pad­ki uży­cia w pro­jek­tach budo­wa­nia sys­te­mów od zera” (tak zwa­nych dedy­ko­wa­nych). Pierwsze, opi­so­we, są od daw­na uzna­ne za złe więc nie będę się nad nimi tu roz­wo­dził i gene­ral­nie odra­dzam ich sto­so­wa­nie. Metody zorien­to­wa­ne na przy­pad­ki uży­cia są coraz czę­ściej uzna­wa­ne za nie­kom­plet­ne gdyż zatra­ca­ją biz­ne­so­wy kon­tekst pro­jek­tu zaś same przy­pad­ki uży­cia nic nie mówią o tak zwa­nych aspek­tach uży­cia sys­te­mu, jego słu­żeb­nej roli w pro­ce­sach biz­ne­so­wych (mowa tu o sys­te­mach wspo­ma­ga­ją­cych zarzą­dza­nie i pokrew­nych). Do tego przy­pad­ki uży­cia są z regu­ły two­rzo­ne z udzia­łem sze­re­go­wych pra­cow­ni­ków, przy­szłych użyt­kow­ni­ków sys­te­mu Ci zaś nie dość, że naj­czę­ściej nie mają poję­cia o cało­ścio­wej stra­te­gii fir­my to z regu­ły poda­ją infor­ma­cje słu­żą­ce ich par­ty­ku­lar­ne­mu chwi­lo­we­mu inte­re­so­wi a nie inte­re­so­wi całej organizacji.

RUP

Jedną z naj­czę­ściej spo­ty­ka­nych w fir­mach deve­lo­per­skich meto­dyk ana­li­zy i pro­jek­to­wa­nia jest Rational Unified Proces (RUP). Jest to typo­wy repre­zen­tant meto­dyk zorien­to­wa­nych na przy­pad­ki uży­cia i opi­su­je jedy­nie ogól­ne zasa­dy two­rze­nia obiek­to­we­go mode­lu sys­te­mu jakim jest tak­że dana orga­ni­za­cja. Metodyka ta bazu­je na nota­cji UML (Unified Modeling Language) ta zaś wspie­ra prak­tycz­nie tyl­ko obiek­to­we meto­dy ana­li­zy i pro­jek­to­wa­nia sys­te­mu a nie samej orga­ni­za­cji. UML nie zawie­ra nota­cji (typ dia­gra­mu) pozwa­la­ją­cej sku­tecz­nie mode­lo­wać orga­ni­za­cje w para­dyg­ma­cie pro­ce­so­wym. Diagram czyn­no­ści w UML sta­no­wi led­wie namiast­kę potrzeb­nych moż­li­wo­ści zaś jego rolą jest tak na praw­dę mode­lo­wa­nie algo­ryt­mów funk­cji (metod obiek­tów). Nawet pod­ręcz­ni­ki RUP’a odwo­łu­ją się do innych nota­cji takich jak eEPC czy od pew­ne­go cza­su BPMN (żr. UML 2.0 w akcji, pod­ręcz­nik opar­ty na pro­jek­tach i inne książ­ki o RUP). Jeżeli coś nowe­go poja­wi­ło się w RUP w kwe­stii two­rze­nia mode­li orga­ni­za­cji chęt­nie poznam tytuł i auto­ra książki.

O języ­kach i teo­rii komunikacji

Niedawno uka­za­ła się cie­ka­wa książ­ka (Inżynieria sys­te­mów infor­ma­cyj­nych, Paul Beynon-Davies), opi­su­je w dość przy­stęp­ny spo­sób daw­no zna­ną z teo­rii komu­ni­ka­cji spo­łecz­nej kwe­stię kon­tek­stu i odbio­ru mode­lu. Błędy w tej mate­rii są postrze­ga­ne, nie tyl­ko prze­ze mnie, jako pod­sta­wo­we źró­dło kło­po­tów w pro­jek­tach IT. Uogólniając nie ma zna­cze­nia czy dany model jest wyko­na­ny popraw­nie od stro­ny syn­tak­tycz­nej (czy popraw­nie połą­czo­no sym­bo­le) i seman­tycz­nej (czy uży­to wła­ści­wych sym­bo­li) w tej czy innej nota­cji. Znaczenie ma to, czy adre­sat popraw­nie i jed­no­znacz­nie go zro­zu­miał (semio­ty­ka mode­lu – to jak zna­ki zosta­ły ode­bra­ne i zro­zu­mia­ne przez obser­wa­to­ra) i nic inne­go się nie liczy.

Model ma dwa zada­nia w ana­li­zie: symu­la­cja rze­czy­wi­stej orga­ni­za­cji dla ana­li­ty­ka i pro­jek­tan­ta oraz udo­ku­men­to­wa­nie decy­zji orga­ni­za­cyj­nych dla mene­dże­rów. Ten dru­gi cel jest z regu­ły zanie­dby­wa­ny i w efek­cie mene­dże­ro­wie zama­wia­ją­cy sys­tem czę­sto pod­pi­su­ją doku­men­ta­cje, któ­rych tak na praw­dę nie rozu­mie­ją pod wpły­wem suge­stii (a bywa, że per­swa­zji!) pseu­do­ana­li­ty­ków dostaw­cy sys­te­mu, że nie muszą tego rozu­mieć ale muszą pod­pi­sać bo to wymóg pro­jek­tu. Nic bar­dziej błędnego!

Istotą opi­su wyma­gań na sys­tem jest kon­tekst całe­go pro­jek­tu i tej inwe­sty­cji a kon­tek­stem tym jest model biz­ne­so­wy zakres pro­jek­tu. Model biz­ne­so­wy moż­na wyko­nać nawet meto­da­mi for­mal­ny­mi za pomo­cą pseu­do­ko­du czy języ­ka rela­cji logicz­nych jed­nak model taki jest bez­war­to­ścio­wy, jeże­li nie sta­no­wi sobą zro­zu­mia­łe­go prze­ka­zu dla każ­de­go zaan­ga­żo­wa­ne­go w pro­jekt czy­taj szcze­gól­nie klien­ta biz­ne­so­we­go”. Kluczem do suk­ce­su jest tu mode­lo­wa­nie czy­li zobra­zo­wa­nie w spo­sób zro­zu­mia­ły dla każ­dej stro­ny w pro­jek­cie IT isto­ty biz­ne­su i jego kon­tek­stu w pro­jek­cie two­rze­nia i wdra­ża­nia opro­gra­mo­wa­nia. Model biz­ne­so­wy i wewnętrz­na struk­tu­ra zarzą­dza­nia orga­ni­za­cji to nie obiek­to­we mode­le a pro­ce­so­we mapy łań­cu­chów two­rze­nia war­to­ści w fir­mie. Model obiek­to­wy ma zasto­so­wa­nie dopie­ro pod­czas two­rze­nia mode­li infor­ma­cyj­nych czy­li struk­tu­ry danych prze­cho­wy­wa­nych i prze­twa­rza­nych w fir­mie a dane to nic inne­go jak repre­zen­ta­cja tych infor­ma­cji, któ­re fir­ma chce prze­twa­rzać oraz spo­sób w jaki chce to robić o czym wie­lu ana­li­ty­ków zda­je się zapo­mi­nać. Jak więc pro­wa­dzić ana­li­zy wymagań?

Na począ­tek moż­na chy­ba pole­cić dość dobrze udo­ku­men­to­wa­ne w lite­ra­tu­rze meto­dy ana­li­zy struk­tu­ral­nej, któ­rej czę­ścią jest mode­lo­wa­nia pro­ce­sów za pomo­cą Diagramów Przepływów Danych. Jako meto­da ana­li­zy i pozy­ski­wa­nia wyma­gań nie­co sie skom­pro­mi­to­wa­ła (bar­dzo pra­co­chłon­na i trud­na w obsza­rze kore­la­cji mode­lu pro­ce­sów i mode­lu danych) jed­nak uczy pro­ce­so­we­go podej­ścia do ana­li­zy. Jako doce­lo­we narzę­dzie pole­cam raczej współ­cze­sne mode­le pro­ce­sów biz­ne­so­wych zorien­to­wa­ne na pro­duk­ty pro­ce­sów (infor­ma­cje). Tu pole­cam prze­stu­dio­wa­nie dostęp­nej w sie­ci doku­men­ta­cji do takich nota­cji i narzę­dzi jak eEPC (pro­gram ARIS), BPMN (www​.omg​.org), ADONIS (wła­sna nota­cja) i wie­le innych w tym wie­le zaawan­so­wa­nych narzę­dzi CASE (Computer Aided System Engineering). Większość tych narzę­dzi ma wbu­do­wa­ną moż­li­wość uży­cia nota­cji BPMN i UML.

Dokumentacje te opi­su­ją głów­nie nota­cję jed­nak na dostęp­nych tam przy­kła­dach moż­na sie nie mało nauczyć. Naczelną zasa­dą mode­lo­wa­nia jed­nak zawsze będzie zro­zu­mia­łość mode­li dla człon­ków mode­lo­wa­nych orga­ni­za­cji. Po dru­gie mode­lo­wa­nie to sztu­ka, nie da się tego nauczyć z jed­nej książ­ki jak rze­mio­sła, nie ma goto­wych pro­ce­dur na wyko­na­nie dobre­go mode­lu. Modelowanie wyma­ga roz­le­głej wie­dzy i doświadczenia.

Na zakoń­cze­nie: nie mode­luj biz­ne­su jeże­li go nie rozumiesz

Na koniec dru­ga waż­na uwa­ga: nie da się mode­lo­wać orga­ni­za­cji i biz­ne­su nie zna­jąc tych dzie­dzin. Modelowanie pro­ce­sów biz­ne­so­wych, jak sama nazwa wska­zu­je, wyma­ga wie­dzy z zakre­su i mode­lo­wa­nia i pro­ce­sów biz­ne­so­wych czy­li zarzą­dza­nia i mar­ke­tin­gu. Dlatego oso­ba pra­gną­ca się nauczyć mode­lo­wa­nia biz­ne­so­we­go może nie musi koń­czyć MBA ale powin­na mieć dużą wie­dzę z zakre­su mar­ke­tin­gu i zarzą­dza­nia. Pamiętając tak­że, że w defi­ni­cji pro­ce­su biz­ne­so­we­go jest two­rze­nie war­to­ści” pole­cam prze­stu­dio­wa­nie lite­ra­tu­ry takiej jak try­lo­gia” M.E.Portera, a przy­naj­mniej jego Przewagę kon­ku­ren­cyj­ną” gdzie dokład­nie jest omó­wio­na teo­ria łań­cu­cha war­to­ści i pro­ce­sy biz­ne­so­we. Polecam tak­że 3. roz­dział (W jaki spo­sób infor­ma­cja wpły­wa na prze­wa­gę kon­ku­ren­cyj­ną, w tym pod­roz­dział Konkurowanie w epo­ce infor­ma­cji) M.E.Porter O kon­ku­ren­cji” gdzie opi­sa­no model łań­cu­cha war­to­ści w biz­ne­sie w posta­ci klu­czo­wych pro­ce­sów fir­my ryn­ko­wej. Jak ktoś ma czas to może zali­czyć tak­że mar­ke­ting” Kottlera to jed­nak jest bar­dziej ope­ra­cyj­ny opis zarzą­dza­nia. Polecam tak­że gorą­ca ZarządzanieP.Druckera.

Podsumowując: sys­te­my dla biz­ne­su two­rzo­ne są na proś­bę tego biz­ne­su by w tym biz­ne­sie poma­gać. Dlatego biz­nes na każ­dym kro­ku musi rozu­mieć opis tego co dosta­nie od ana­li­ty­ka wyma­gań zaś na począ­tek nale­ży opi­sać (zamo­de­lo­wać) sam biz­nes i do tego potrzeb­ne są mię­dzy inny­mi mode­le biz­ne­so­we i mode­le pro­ce­sów biznesowych.

Metodyki inży­nie­rii opro­gra­mo­wa­nia, sto­so­wa­ne tak­że w ana­li­zie wyma­gań na tak zwa­ne goto­we sys­te­my”, zorien­to­wa­ne na model biz­ne­so­wy i model dzie­dzi­ny sys­te­mu nale­żą do naj­sku­tecz­niej­szych i para­dok­sal­nie naj­rza­dziej sto­so­wa­nych. Dlaczego? Moim zda­niem wła­śnie dla­te­go, że w wie­lu przy­pad­kach pomi­ja sie etap rze­tel­nej ana­li­zy biz­ne­so­wej w pro­jek­tach IT pozwa­la­jąc, by opis wyma­gań wyko­nał od razu inży­nier bo to taniej”.

2010 r. Notatka: Zdaniem ana­li­ty­ków fir­my decy­du­ją­ce się na wdro­że­nie sys­te­mu ERP mogą unik­nąć roz­jeż­dza­ją­cych się ter­mi­nów i nad­mier­nie wyso­kich kosz­tów dzię­ki odpo­wied­nio prze­pro­wa­dzo­nej ana­li­zie przed­wdro­że­nio­wej. Eksperci pod­kre­śla­ją bowiem, że więk­szość kosz­tów gene­ro­wa­nych przez pro­jekt wdro­że­nio­wy nie ma nic wspól­ne­go z kosz­tem same­go opro­gra­mo­wa­nia. Średnio trzy czwar­te budże­tu pochła­nia­ją kosz­ty wdro­że­nia, mody­fi­ka­cji stan­dar­do­wej funk­cjo­nal­no­ści oraz moder­ni­za­cji sprzę­tu” – czy­ta­my w rapor­cie Panorama Consulting Group.” (źr. IDG, 2010r)

P.S. 2016 r. 

Osobom zain­te­re­so­wa­nym pole­cam opis jed­nej z meto­dyk ana­li­zy wyma­gań i pro­jek­to­wa­nia zorien­to­wa­nych na model biz­ne­so­wy i model dzie­dzi­ny sys­te­mu wraz z przy­kła­do­wym pro­jek­tem opi­sa­ny w mojej książ­ce Analiza Biznesowa.