Diagram aktywności UML – kiedy

Wstęp

Od cza­su do cza­su jestem pyta­ny o to, kie­dy uży­wać dia­gra­mu aktyw­no­ści UML. Od 2015 roku spe­cy­fi­ka­cja UML wska­zu­je, że dia­gra­my te są narzę­dziem mode­lo­wa­nia metod czy­li logi­ki kodu (dla Platform Independent Model): aktyw­no­ści (acti­vi­ties) to nazwy metod, zadania/kroki (actions) to ele­men­ty kodu (przy­kła­dy w dal­szej części). 

Gdy powsta­wał UML, dia­gra­my aktyw­no­ści były uży­wa­ne tak­że do mode­lo­wa­nie pro­ce­sów biz­ne­so­wych. W roku 2004 opu­bli­ko­wa­no spe­cy­fi­ka­cję nota­cji BPMN, któ­ra w zasa­dzie do roku 2015 prze­ję­ła” po UML funk­cję narzę­dzia mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. W 2015 roku for­mal­nie opu­bli­ko­wa­no spe­cy­fi­ka­cję UML 2.5, gdzie gene­ral­nie zre­zy­gno­wa­no z uży­wa­nia UML do mode­li CIM. Obecnie Mamy usta­bi­li­zo­wa­ną sytu­ację w lite­ra­tu­rze przed­mio­tu: BPMN wyko­rzy­stu­je­my w mode­lach CIM (mode­le biz­ne­so­we), UML w mode­lach PIM i PSM jako mode­le opro­gra­mo­wa­nia (a mode­le sys­te­mów: SysML, pro­fil UML). 

Na prze­ło­mie lat 80/90-tych roz­po­czę­to pra­ce nad stan­da­ry­za­cję nota­cji mode­lo­wa­nia obiek­to­we­go, w 1994 opu­bli­ko­wa­no UML 0.9, w 2001 roku poja­wia­ją się pierw­sze publi­ka­cje o pra­cach nad nota­cją BPMN, jed­no­cze­śnie poja­wia się Agile Manifesto, od 2004 roku ma miej­sce spa­dek zain­te­re­so­wa­nia doku­men­to­wa­niem pro­jek­tów pro­gra­mi­stycz­nych, w 2004 rok publi­ko­wa­no spe­cyf­ka­cję BPMN 1.0, od tego roku ma miej­sce wzrost zain­te­re­so­wa­nia mode­lo­wa­niem pro­ce­sów biz­ne­so­wych, powo­li sta­bi­li­zu­je się obszar zasto­so­wa­nia nota­cji UML. W 2015 roku opu­bli­ko­wa­no UML 2.5, sto­so­wa­nie ana­li­zy (CIM) i i pro­jek­to­wa­nia (PIM), jako eta­pu poprze­dza­ją­ce­go imple­men­ta­cje, sta­ło się stan­dar­dem (źr. wykre­su: Google Ngram).

Tak więc obecnie: 

Nie uży­wa­my dia­gra­mów aktyw­no­ści do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Do tego słu­ży nota­cja BPMN!

Diagram aktyw­no­ści może być mode­lem kodu na wyso­kim lub niskim pozio­mie abs­trak­cji, ope­ru­je­my wte­dy odpo­wied­nio aktyw­no­ścia­mi (acti­vi­ty) lub dzia­ła­nia­mi (actions). Te ostat­nie to w zasa­dzie repre­zen­ta­cja pole­ceń programu. 

Nie ma cze­goś takie­go jak pro­ces sys­te­mo­wy”, opro­gra­mo­wa­nie reali­zu­je pro­ce­du­ry”.

Projektując opro­gra­mo­wa­nie zgod­nie ze SPEM , powsta­je Platform Independent Model. W prak­ty­ce już na tym eta­pie pro­gra­mu­je­my, bo two­rzy­my logi­kę i obraz przy­szłe­go kodu. Taka for­ma doku­men­to­wa­nia pozwa­la tak­że lepiej chro­nic war­to­ści inte­lek­tu­al­ne zamawiającego.

Czytaj dalej… Diagram aktyw­no­ści UML – kie­dy”

Projekt aplikacji – przykład

Wstęp

Napisałem o orien­ta­cji na doku­men­ty w toku analiz:

Często jestem i ja pyta­ny o to ??Jak wyja­śnić zło­żo­ne roz­wią­za­nie tech­nicz­ne inte­re­sa­riu­szom nie­tech­nicz­nym?? Jak wie­lu mi podob­nych odpo­wia­dam: roz­ma­wiaj doku­men­ta­mi. Sponsor pro­jek­tu, przy­szli użyt­kow­ni­cy, postrze­ga­ją swo­ją pra­cę poprzez doku­men­ty: ich treść i układ. (Wymagania na for­mu­la­rze czy­li dia­gra­my struk­tur zło­żo­nych i XML)

Dzisiaj pój­dzie­my dalej, omó­wi­my to gdzie i jak zacho­wać tę infor­ma­cję. Posłużę się pro­stym przy­kła­dem przy­chod­ni wete­ry­na­ryj­nej. Artykuł będzie opi­sem meto­dy podej­ścia do ana­li­zy zorien­to­wa­nej na pro­ce­sy i dokumenty. 

Tekst ma dwie czę­ści: pierw­sza jest opi­sem dro­gi jaka pro­wa­dzi nas do zde­fi­nio­wa­nia tego jakie doku­men­ty, jaką mają (mieć) zawar­tość i struk­tu­rę. Praktycznie jest to opis ana­li­zy i pro­jek­to­wa­nia. Druga – krót­ka – to przy­kła­do­wa archi­tek­tu­ra logi­ki reali­za­cji apli­ka­cji, poka­zu­ją­ca miej­sce doku­men­to­wej bazy danych w archi­tek­tu­rze i pro­jek­cie, czy­li tak­że projektowanie. 

Celem tego wpi­su jest poka­za­nie czym może być ana­li­za oraz jej pro­dukt jakim jest Techniczny Projekt Oprogramowania.

Czytaj dalej… Projekt apli­ka­cji – przy­kład”

Ochrona oprogramowania a prawo autorskie – wartości intelektualne w umowach

Wstęp

W lutym 2017 r. opi­sy­wa­łem praw­ne aspek­ty poję­cia przed­miot zamó­wie­nia” w sfe­rze inży­nie­rii opro­gra­mo­wa­nia. Niedawno uka­zał się w pra­sie arty­kuł o domnie­ma­nym pla­no­wa­niu wywłasz­cze­nia programistów:

Sejm jest o włos od znie­sie­nia mecha­ni­zmu ochro­ny autor­skiej twór­ców apli­ka­cji. Na razie tych, któ­rzy infor­ma­ty­zo­wa­li sądy, pro­ku­ra­tu­ry i komor­ni­ków. 1

Wywołał on spo­rą burzę w bran­ży IT, nie­ste­ty więk­szość publi­ko­wa­nych w mediach wypo­wie­dzi jest bar­dzo powierz­chow­na a nie­ste­ty bar­dzo czę­sto wręcz fał­szy­wa. Do tego nakła­da­ją się wypo­wie­dzi lob­by­stów z bran­ży IT, nie­jed­no­krot­nie prze­mil­cza­ją­ce pew­ne fak­ty a nie raz sta­wia­ją­ce wręcz nie­praw­dzi­we tezy. Otóż, o czym nie raz pisa­łem, stale …

W prze­strze­ni publicz­nej toczą się spo­ry co do tego ?czym jest opro­gra­mo­wa­nie?, jed­nak moim zda­niem, więk­szość tych spo­rów ma swo­je źró­dła w nie­zro­zu­mie­niu spe­cy­fi­ki tech­no­lo­gii infor­ma­tycz­nych i same­go pra­wa, część jest skut­kiem celo­we­go lub nie, mata­cze­nia w samych umo­wach. Ustawodawca, moim zda­niem bar­dzo słusz­nie, zakwa­li­fi­ko­wał opro­gra­mo­wa­nie do utwo­rów lite­rac­kich, gdyż w swej isto­cie jest ono zawsze zapi­sem ana­lo­gicz­nym do tek­stu. Osobną kwe­stią jest treść tkwią­ca w takim utwo­rze (o czym on jest), co podob­nie jak w przy­pad­ku lite­rac­kich tek­stów, może mieć ale nie musi, zna­cze­nie. Tekst Kodu pro­gra­mu zin­ter­pre­to­wa­na przez odpo­wied­nią maszy­nę, potocz­nie zwa­ną kom­pu­te­rem, decy­du­je o tym ?czym dany kom­pu­ter jest?. Raz jest pro­gra­ma­to­rem pral­ki a raz edy­to­rem tek­stu czy grą inte­rak­tyw­ną. Oprogramowanie czę­sto cechu­je się okre­ślo­nym ?mecha­ni­zmem dzia­ła­nia?. W lite­ra­tu­rze z obsza­ru tech­nik kom­pu­te­ro­wych i filo­zo­fii, bar­dzo czę­sto moż­na spo­tkać teo­rię mówią­cą, że ?kom­pu­ter to uni­wer­sal­ny mecha­nizm?. Innymi sło­wy kom­pu­ter może być ?czym­kol­wiek?, decy­du­je o tym ?pro­gram kom­pu­te­ro­wy?. 2

Jeżeli nało­ży­my na to fakt, że zama­wia­ją­cy w więk­szo­ści nie zna­ją i nie rozu­mie­ją praw­nych aspek­tów ochro­ny war­to­ści inte­lek­tu­al­nych, to mamy do czy­nie­nia z obec­nym ogrom­nym bała­ga­nem, nie tyl­ko w admi­ni­stra­cji publicz­nej, ale i z tym jakie i kto ma pra­wa do wyko­rzy­sty­wa­ne­go opro­gra­mo­wa­nia. Niestety prze­wa­ga mery­to­rycz­na jaką ma bran­ża IT nad swo­imi klien­ta­mi pozwa­la na wie­le nad­użyć, szcze­gól­nie w sfe­rze zawłasz­cza­nia know-how przez twór­ców oprogramowania.

Wartości intelektualne w umowach

Dzisiaj opi­szę kwe­stie praw­no-autor­skie wła­śnie z per­spek­ty­wy war­to­ści inte­lek­tu­al­nych w umo­wach. Kluczem jest upo­rząd­ko­wa­nie pojęć wyko­rzy­sty­wa­nych w umo­wach i ustawach.

Poniższy dia­gram to model poję­cio­wy wyko­na­ny w nota­cji SBVR (dia­gram fak­tów) 3:

Model poję­cio­wy dla praw autor­skich i wła­sno­ści inte­lek­tu­al­nej (opr. Jarosław Żeliński)

Opiszę treść dia­gra­mu. Poszczególne poję­cia zosta­ły zobra­zo­wa­ne jako pro­sto­ką­ty. Linie mię­dzy nimi to fak­ty łączą­ce je para­mi w okre­ślo­ny kon­tekst. Strzałki łączą poję­cia ogól­ne z ich szcze­gól­ny­mi typa­mi. Kluczowe poję­cia: utwór, know-how oraz pole eks­plo­ata­cji, zosta­ły opi­sa­ne cyta­ta­mi z aktów praw­nych. Zestaw powią­za­nych kon­tek­stem pojęć nazy­wa­my prze­strze­nią pojęciową.

Treść to zawar­tość wypo­wie­dzi lub doku­men­tu 4. Zawartością może być (treść nie­sie) ta zwa­ne know-how. Jeżeli treść ma indy­wi­du­al­ny cha­rak­ter, jest utwo­rem. Zgodnie z pra­wem jest nim każ­da treść o indy­wi­du­al­nym cha­rak­te­rze, w szcze­gól­no­ści spe­cy­fi­ka­cja (pro­jekt tech­nicz­ny) i kod pro­gra­mu kom­pu­te­ro­we­go. Oba są utwo­ra­mi w rozu­mie­niu pra­wa. Użytkownika korzy­sta z apli­ka­cji (jest ona opro­gra­mo­wa­niem), ta może być wyra­żo­na z pomo­cą sym­bo­li, wzo­rów i sche­ma­tów blo­ko­wych lub/i w posta­ci kodu pro­gra­mu. Należy pamię­tać, co bar­dzo waż­ne w bran­ży inży­nier­skiej, że …

Program kom­pu­te­ro­wy napi­sa­ny na pod­sta­wie opra­co­wa­ne­go wcze­śniej pro­jek­tu (podob­nie jak każ­de inne roz­wią­za­nie lub pro­dukt) sta­no­wi utwór zależ­ny (jest to reali­za­cja pro­jek­tu). Utworem pier­wot­nym dla opro­gra­mo­wa­nia jest tu pro­jekt tego opro­gra­mo­wa­nia (jeże­li powstał), w tym jego uni­kal­na archi­tek­tu­ra. Oprogramowanie powsta­łe na pod­sta­wie pro­jek­tu inne­go auto­ra, powin­no zostać ozna­czo­ne dany­mi auto­ra tego pro­jek­tu 5

Tak więc, jeże­li kod powstał na pod­sta­wie spe­cy­fi­ka­cji, jest utwo­rem (dzie­łem) zależ­nym, jeże­li nie, jest samo­dziel­nym utwo­rem. Wśród wie­lu pól eks­plo­ata­cji utwo­ru są wydru­ki i uru­cha­mia­nie w pamię­ci komputera.

Wnioski dla nabywców oprogramowania

Przede wszyst­kim nale­ży pod­jąć decy­zję o tym co licen­cjo­nu­je­my, do cze­go naby­wa­my pra­wa mająt­ko­we i na jakich polach eks­plo­ata­cji. Tak zwa­ne opro­gra­mo­wa­nie stan­dar­do­we to pro­duk­ty ryn­ko­we sprze­da­wa­ne do wie­lu pod­mio­tów, tu może­my liczyć na okre­ślo­ną for­mę licen­cji. Jak użyt­kow­nik naj­czę­ściej na uru­cha­mia­nie w pamię­ci kom­pu­te­ra, ale nie na dys­try­bu­cję. Taki zakup jest rela­tyw­nie pro­sty a umo­wy licen­cyj­ne są stan­dar­do­we dla dane­go pro­du­cen­ta i produktu.

Problemem jest zle­ce­nie wyko­na­nia dedy­ko­wa­ne­go dla nas opro­gra­mo­wa­nia. Kod pro­gra­mu jest utwo­rem, utwór jako treść nie­sie (zakła­da­my, że tak jest) know-how fir­my zle­ca­ją­ce wyko­na­nie dla sie­bie dedy­ko­wa­ne­go opro­gra­mo­wa­nia (spe­cy­fi­ka logi­ki biz­ne­so­wej, mecha­ni­zmy dzia­ła­nia róż­nych funk­cji itp.). Na pyta­nie czy wyko­naw­ca musi nam prze­ka­zać w umo­wie praw mająt­ko­we? Może ale nie musi (wte­dy suge­ru­ję nie zawie­ra­nie umo­wy i szu­ka­nie inne­go wyko­naw­cy). Jednak jeże­li zama­wia­ją­cy naj­pierw opra­cu­je spe­cy­fi­ka­cję (to tak­że utwór, zawie­ra dokład­ny opis wyko­na­nia opro­gra­mo­wa­nia) i uczy­ni z niej ele­ment umo­wy na wyko­na­nie dla nie­go opro­gra­mo­wa­nia, wyko­naw­ca nie ma żad­nych praw (o ile mu ich nie prze­ka­że­my) do dys­po­no­wa­nia tak wytwo­rzo­nym oprogramowaniem.

W pro­jek­tach dużych, klu­czo­wą czę­ścią powi­nien być pro­jekt archi­tek­tu­ry, uwzględ­nia­ją­cy pra­wa do poszcze­gól­nych kom­po­nen­tów oraz sepa­ro­wa­nie kom­po­nen­tów stan­dar­do­wych od tych zawie­ra­ją­cych nasze know-how. To dla­te­go naj­wię­cej szkód przy­no­si kupu­ją­cym opro­gra­mo­wa­nie tak czę­sto ofe­ro­wa­na przez dostaw­ców kasto­mi­za­cja… czy­li wbu­do­wy­wa­nie logi­ki biz­ne­so­wej kupu­ją­ce­go we wła­sny już kod, tu ma miej­sce cał­ko­wi­te prze­ję­cie know-how przez dostaw­ce oprogramowania.

Nie będę opi­sy­wał deta­li takich umów (a są one istot­ne), gdyż celem moim było opi­sa­nie mecha­ni­zmów praw­nych ich kon­stru­owa­nia i mecha­ni­zmów ochro­ny. Chciałem tu przede wszyst­kim wska­zać mecha­nizm nad­użyć pole­ga­ją­cy na tym, że: dostaw­ca opro­gra­mo­wa­nia ofe­ru­je (for­su­je) pra­cę bez uprzed­nie­go spe­cy­fi­ko­wa­nia apli­ka­cji (tak zwa­ne zwin­ne pro­jek­ty agi­le) lub ofe­ru­je samo­dziel­ne wyko­na­nie takiej spe­cy­fi­ka­cji (pod nazwą ana­li­za wyma­gań, ana­li­za przed-wdro­że­nio­wa itp.). W obu przy­pad­kach peł­nię praw autor­skich (oso­bi­ste i mająt­ko­we) pozo­sta­ją przy twór­cy kodu. Pozycja nego­cja­cyj­na nabyw­cy jest tu bar­dzo sła­ba. Dzięki temu mecha­ni­zmo­wi bar­dzo wie­le form pro­du­ku­ją­cych opro­gra­mo­wa­nie wymu­sza na admi­ni­stra­cji publicz­nej zaku­py z wol­nej ręki, podob­nie zresz­tą w fir­mach pry­wat­nych: mono­po­li­zu­ją pra­wa do opro­gra­mo­wa­nia i prak­tycz­nie cał­ko­wi­cie blo­ku­ją kon­ku­ren­cję a użyt­kow­ni­ka ska­zu­ją na sie­bie jako dostaw­ce usług utrzy­ma­nia i rozwoju.

Dlatego nie­za­leż­nie od tego co sądzi­my o meto­dach zwin­nych, war­to zadbać o swo­je know-how i doku­men­to­wać je. Nie war­to tak­że zle­cać prac ana­li­tycz­no-pro­jek­to­wych pro­du­cen­tom oprogramowania.

Wspomniane na począt­ku wywłasz­cza­nie” pro­gra­mi­stów ma zara­dzić takim nad­uży­ciom na przy­szłość. Osobną jed­nak kwe­stią, nie na ten arty­kuł, jest spo­sób prze­pro­wa­dze­nia tego.

___

2017-08-07 Temat stał się na tyle gorą­cy, że Pani red. Sylwia Czubkowska w Gazecie Prawnej kon­ty­nu­owa­ła temat w roz­mo­wie ze mną:

? Doradzałbym szklan­kę zim­nej wody. Owszem, ten prze­pis jest źle napi­sa­ny, ale nie jest wca­le bez­pod­staw­ny. To, że w tym wypad­ku resort spra­wie­dli­wo­ści, a za chwi­lę może po pro­stu rząd, myśli o tym, by usta­wo­wo naka­zać prze­ka­za­nie kodów źró­dło­wych, z któ­rych korzy­sta admi­ni­stra­cja, nie jest wca­le nie­uza­sad­nio­ne ? oce­nia Jarosław Żeliński, zało­ży­ciel i głów­ny ana­li­tyk fir­my IT-Consulting, zaj­mu­ją­cej się doradz­twem przy inwe­sty­cjach w nowe tech­no­lo­gie. ? Ustawowe wywłasz­cze­nie to meto­da skraj­na, ale nie­ste­ty może oka­zać się cza­sa­mi nie­zbęd­ne. Przecież pań­stwo, czy­li jego insty­tu­cje, za te pro­gra­my fir­mom zapła­ci­ło, a w nie­jed­nym przy­pad­ku wca­le nie dosta­ło peł­no­war­to­ścio­we­go pro­duk­tu. Często z wła­snej winy, bo nie dopil­no­wa­ło od razu, by zabez­pie­czyć swo­je pra­wa tak­że do kodów. A bez nich nie­ste­ty pro­dukt jest nie­peł­no­war­to­ścio­wy. Czasem jed­nak taka kon­struk­cja umów to poli­ty­ka firm, któ­re kodów nie chcą prze­ka­zy­wać ? tłu­ma­czy eks­pert. A nie chcą, bo dzię­ki temu insty­tu­cja publicz­na ? nie mając kodów ? jest zmu­szo­na, by kolej­ne zle­ce­nia dawać ich wła­ści­cie­lo­wi. (6)

__________________
2.
Zelinski J. Przedmiot Zamówienia ? instruk­cja nie tyl­ko dla praw­ni­ków, na zupę pomi­do­ro­wą. Jarosław Żeliński IT-Consulting. https://it-consulting.pl//2017/02/16/przedmiot-zamowienia-instrukcja-dla-prawnikow-na-zupe-pomidorowa/. Published February 16, 2017. Accessed July 17, 2017.
3.
SBVR. OMG​.org. http://​www​.omg​.org/​s​p​e​c​/​S​B​VR/. Accessed July 17, 2017.
4.
treść – defi­ni­cja, syno­ni­my, przy­kła­dy uży­cia. SJP​.pwn​.pl. https://sjp.pwn.pl/szukaj/tre%C5%9B%C4%87.html. Accessed July 17, 2017.
5.
Zelinski J. Ochrona know-how nabyw­cy opro­gra­mo­wa­nia. Jarosław Żeliński IT-Consulting. https://it-consulting.pl//prawa-autora-analizy-i-ochrona-know-how-organizacji-analizowanej/. Accessed July 17, 2017.

Wymagania ? Zarządzanie wersjami

Pomijając ich warian­ty, sto­so­wa­ne są dwie meto­dy (gru­py metod) doku­men­to­wa­nia wyma­gań i zarzą­dza­nia nimi. Zakładamy, że są to wyma­ga­nia wobec pro­duk­tu (roz­wią­za­nia) jaki ma dostar­czyć jego dostaw­ca. W BABoK (Business Analysis Body of Knowledge), wyma­ga­nia te musi speł­nić dostar­czo­ny pro­dukt, jed­nak oczy­wi­ście roz­li­cza­ny jest dostaw­ca rozwiązania.

Stosowane są trzy meto­dy (gru­py metod) spe­cy­fi­ko­wa­nia wymagań:

  1. Specyfikacja wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych (i warian­ty tej metody).
  2. Specyfikowanie tak zwa­nej czar­nej skrzyn­ki” (przy­pad­ki użycia).
  3. Specyfikowanie tak zwa­nej bia­łe skrzyn­ki” (przy­pad­ki uży­cia + model dzie­dzi­ny systemu).

Pierwsza i naj­star­sza meto­da bazu­je na zało­że­niu, że zama­wia­ją­cy i (lub) przy­szły użyt­kow­nik wie cze­go chce. Wymagania w posta­ci listy (funk­cjo­nal­ne i poza-funk­cjo­nal­ne) kolek­cjo­no­wa­ne są na warsz­ta­tach, burzach mózgów, tak zwa­nych sesjach JAD (ang. [[Joint Application Development]]), bywa, że z pomo­cą ankiet. Powstaje lista (tabe­la) z odpo­wied­nio ozna­czo­ny­mi i skla­sy­fi­ko­wa­ny­mi wymaganiami.

Czarna skrzyn­ka” to wyma­ga­nia opra­co­wa­ne w posta­ci opi­su roz­wią­za­nia sku­pia­ją­ce­go się wyłącz­nie na jego zewnętrz­nych cechach, zmu­sza do wyspe­cy­fi­ko­wa­nia tego do cze­go ma ono słu­żyć, jed­nak nie opi­su­je mecha­ni­zmu jego dzia­ła­nia, spe­cy­fi­ka­cja przy­pad­ków uży­cia w zasa­dzie zamy­ka się na udo­ku­men­to­wa­niu bodź­ca i efek­tu (stan począt­ko­wy i koń­co­wy) każ­de­go przy­pad­ku uży­cia (usłu­gi spe­cy­fi­ko­wa­nej apli­ka­cji), wyja­śnie­nie np. spo­so­bu wyko­na­nia obli­czeń – owszem – doku­men­to­wa­ne jest w posta­ci np. wzo­rów mate­ma­tycz­nych czy algo­ryt­mów, jed­nak taka cecha jak np. moż­li­wość sko­ja­rze­nia wszyst­kich zamó­wień, na bazie któ­rych powsta­ła zbior­cza fak­tu­ra na koniec mie­sią­ca” pozo­sta­je tyl­ko nazwa­nym wyma­ga­niem, spe­cy­fi­ka­cja taka nie zawie­ra opi­su mecha­ni­zmu pozwa­la­ją­ce­go na taka operację.

Biała skrzyn­ka” to spe­cy­fi­ka­cja jak wyżej, uzu­peł­nio­na o opis (model) np. mecha­ni­zmu pozwa­la­ją­ce­go na sko­ja­rze­nie tych zamó­wień z wła­ści­wą fakturą.

BABoK gene­ral­nie wska­zu­je (sku­pia się) na dwóch ostat­nich metodach.

W każ­dym pro­jek­cie trwa­ją­cym w cza­sie i dopusz­cza­ją­cym zmia­ny w jego zakre­sie (w wyma­ga­niach) poja­wia się potrze­ba zarzą­dza­nia zmia­na­mi, zaspo­ka­ja­na prak­tycz­nie zawsze z pomo­cą tak zwa­ne­go wer­sjo­no­wa­nia. Wersjonowanie wyma­gań w posta­ci pła­skiej listy wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych, jest żmud­ne, spro­wa­dza się do nie­za­leż­ne­go wer­sjo­no­wa­nia tre­ści (brzmie­nia) każ­de­go wyma­ga­nia wraz z moż­li­wo­ścią poja­wie­nia się nowe­go i usu­nię­cia już ist­nie­ją­ce­go (lub nada­nia mu sta­tu­su odrzu­co­ne”). Opisał to ład­nie Miał Wolski:

Zmiany w wyma­ga­niach wyma­ga ich wer­sjo­no­wa­nia. Wersje wyma­gań poma­ga­ją uzy­skać dostęp do okre­ślo­ne­go sta­nu wyma­ga­nia w trak­cie życia opro­gra­mo­wa­nia. Najczęściej wer­sje wyma­gań okre­śla­ne są za pomo­cą kolej­nych ich nume­rów. Najbardziej popu­lar­nym spo­so­bem nada­wa­nia nume­rów wyma­gań jest zło­że­nie nume­ru z wer­sji wyma­ga­nia oraz przy­ro­stu, oddzie­lo­nych zna­kiem krop­ki. Wersja 1.3 ozna­cza wte­dy 1 wer­sję wyma­ga­nia i 3 przy­rost. (Źródło: Wymagania ? Zarządzanie wer­sja­mi | Michał Wolski)

Zupełnie ina­czej wyglą­da w pozo­sta­łych dwóch meto­dach. Zarówno czar­na skrzyn­ka” jak i jej bia­ła” odmia­na, to są już pro­jek­ty roz­wią­za­nia (np. apli­ka­cji), bia­ła skrzyn­ka” zawie­ra wewnętrz­ną archi­tek­tu­rę. Wobec tego jest to jeden pro­jekt” a nie np. czte­ry­sta wyma­gań”. Wersjonowaniu pod­le­ga tu jeden pro­jekt, dzię­ki temu sam pro­ces wer­sjo­no­wa­nia i zarzą­dza­nie nim sta­je się znacz­nie prost­szy (moż­na to robić np. z pomo­cą sys­te­mów zarzą­dza­nia wer­sja­mi taki­mi jak [[CVS]], [[SVR]] itp.). Owszem, pro­jekt może zawie­rać wie­le deta­li, żeby uła­twić zna­le­zie­nie róż­ni­cy mię­dzy wer­sja­mi (tego co zosta­ło wła­śnie zmie­nio­ne) na począt­ku doku­men­tu (spe­cy­fi­ka­cji pro­jek­tu) umiesz­cza się tak zwa­ny regestr zmian (doty­czy całe­go projektu).

Opracowanie listy wyma­gań funk­cjo­nal­nych i poza funk­cjo­nal­nych jest rela­tyw­nie naj­prost­sze, nie wyma­ga od pra­cow­ni­ków zama­wia­ją­ce­go dodat­ko­wych kwa­li­fi­ka­cji, mogą w tym pro­ce­sie brać udział przy­szli użyt­kow­ni­cy, jed­nak utrzy­ma­nie kom­plet­no­ści, spój­no­ści i nie­sprzecz­no­ści takiej spe­cy­fi­ka­cji jest najtrudniejsze.

W przy­pad­ku skrzy­nek” już sam fakt, że są one pro­jek­tem (pew­ną kon­struk­cją) pozwa­la sto­so­wać do ich opi­su typo­we inży­nier­skie meto­dy takie jak mode­lo­wa­nie. Model moż­na testo­wać więc zagwa­ran­to­wa­nie spój­no­ści, kom­plet­no­ści i nie­sprzecz­no­ści jest łatwiej­sze, pro­ble­mem pozo­sta­je co naj­wy­żej kom­plet­ność, czy­li odpo­wiedź na pyta­nie Czy to są wszyst­kie wyma­ga­ne funk­cje”. Ryzyko jakie stwa­rza czar­na skrzyn­ka” to pozo­sta­wie­nie dostaw­cy (wyko­naw­cy, deve­lo­pe­ro­wi) decy­zji o posta­ci mecha­ni­zmu dzia­ła­nia (jego zapro­jek­to­wa­nie). Dostawca może go zbyt upro­ścić lub wręcz nie rozu­mieć i powsta­nie coś co nie reali­zu­je w 100% logi­ki biz­ne­so­wej danej orga­ni­za­cji. Biała skrzyn­ka” niwe­lu­je to ryzy­ko: powsta­je tu pro­jekt wewnętrz­nej logi­ki: mecha­nizm dzia­ła­nia aplikacji.

Konsekwencje. Wydawało by się, że pierw­sza meto­da jest naj­tań­sza, bo pro­jek­to­wa­nie jest kosz­tow­niej­szą pra­cą bo wyma­ga znacz­nie więk­szych kom­pe­ten­cji niż pro­wa­dze­nie warsz­ta­tów, sam przy­szły użyt­kow­nik z regu­ły nie posia­da tych kom­pe­ten­cji i musi za nie zapła­cić. Niestety jest to praw­da dla małych pro­jek­tów, tam gdzie poja­wia­ją się wyma­ga­nia w ilo­ści setek i nie raz tysię­cy, samo zarzą­dza­nie nimi jest tak pra­co­chłon­ne, że koszt rośnie szyb­ciej niż licz­ba tych wymagań.

Po prze­kro­cze­niu pew­ne­go pozio­mu zło­żo­no­ści znacz­nie lep­sze są meto­dy sys­te­mo­we opar­te na pro­jek­to­wa­niu („skrzyn­ki”), i tu waż­na uwa­ga: pro­jek­to­wa­nie to etap spe­cy­fi­ko­wa­nia wyma­gań, jeże­li pro­jekt opra­cu­je zama­wia­ją­cy, niwe­lu­je ryzy­ka jakie nie­sie ze sobą zle­ce­nie pro­jek­to­wa­nia deve­lo­pe­ro­wi: praw­do­po­dob­nie będzie uprasz­czał pro­jekt (obni­żał swój koszt) i bar­dzo praw­do­po­dob­ne, że będzie for­so­wał swo­je dotych­cza­so­we doświad­cze­nie z fir­my o podob­nym cha­rak­te­rze co nie­ste­ty bar­dzo czę­sto pro­wa­dzi do nie­upraw­nio­ne­go powie­le­nie cudzej i nie­ko­niecz­nie dobrej, logi­ki biz­ne­so­wej. Do tego poja­wia się pro­blem (duże ryzy­ko) zawłasz­cze­nia przez dostaw­cę praw autor­skich do pro­jek­tu tej biz­ne­so­wej logi­ki i całe­go mecha­ni­zmu dzia­ła­nia apli­ka­cji a tym samym orga­ni­za­cji (o czym nie raz tu już pisa­łem).