Opis wymagań z użyciem Gherkin – czyli duuużo korniszonów…

Wstęp

Zostałem nie­daw­no zapy­ta­ny czy pomo­gę bo mamy już ponad 150 przy­pad­ków uży­cia w doku­men­ta­cji…”. Myślę sobie, to nie­moż­li­we, nie ma tak wiel­kich sys­te­mów (wyce­na oka­za­ła się w efek­cie pię­cio­krot­nie zawy­żo­na tyl­ko dla­te­go, że uży­to meto­dy zorien­to­wa­nej na user story”). 

Czytaj dalej… Opis wyma­gań z uży­ciem Gherkin – czy­li duuużo kor­ni­szo­nów…”
Struktura projektu UML

V‑model i zarządzanie jakością

Ten arty­kuł to krót­ki wpis o tak zwa­nym V‑modelu. Jest to model wytwa­rza­nia opar­ty na pętli ana­li­zy, pro­jek­to­wa­nia, testo­wa­nia i prze­ka­za­nia do użyt­ku. Oparty jest połą­cze­niu dwóch cykli życia: pro­jek­to­wa­nia i wytwa­rza­nia. jest sto­so­wa­ny w sze­ro­ko poję­tej inży­nie­rii sys­te­mów, nie koniecz­nie oprogramowania. 

W bran­ży IT zna­na jego postać wyglą­da np. tak:

V‑Model is also refer­red to as the Verification and Validation Model. In this, each pha­se of SDLC must com­ple­te befo­re the next pha­se starts. It fol­lows a sequ­en­tial design pro­cess the same as the water­fall model. The testing of the devi­ce is plan­ned in paral­lel with a cor­re­spon­ding sta­ge of deve­lop­ment. (źr.: V‑model (Software Engineering) – javat­po­int).

Niedawno w innej wer­sji v‑model publi­ko­wa­łem, pisząc o tym czym jest mecha­tro­ni­ka :

Bardzo czę­sto auto­rzy piszą, że jest to skom­pro­mi­to­wa­ny, tak zwa­ny wodo­spa­do­wy (water­fall), sys­tem wytwa­rza­nia opro­gra­mo­wa­nia. Była by to praw­da, gdy zawsze cho­dzi­ło o hipo­te­tycz­ny cały sys­tem”. Jednak V‑model, jako meto­da, nie pre­cy­zu­je ska­li pro­jek­tu. W przy­pad­ku więk­szo­ści daw­nych kon­struk­cji mecha­nicz­nych była by to praw­da, jed­nak modu­ło­wość to od lat cecha każ­dej kon­struk­cji inży­nier­skiej. Model ten więc nie koniecz­nie musi być tym złym wodo­spa­dem”. Pojawiają się od cza­su do porów­na­nia mię­dzy wodo­spa­dem, v‑modelem a agi­le, jako meto­da­mi, jed­nak ich auto­rzy nie pre­cy­zu­ją tego, czy w danym przy­pad­ku cho­dzi o moduł czy o cały sys­tem . Model ten jest sta­le przed­mio­tem poszu­ki­wań popra­wy jako­ści i więk­szej zwin­no­ści” .

Myślę, że kla­sycz­ny wodo­spad, jako meto­da pro­wa­dze­nia powo­li odcho­dzi w nie­pa­mięć (powi­nien). Nie zapo­mi­naj­my jed­nak, że roz­po­czy­na­nie two­rze­nia opro­gra­mo­wa­nia od pro­jek­to­wa­nia wspól­ne­go (rela­cyj­ne­go) mode­lu danych to taki wła­śnie kla­sycz­ny struk­tu­ral­ny wodo­spad. Więc jak?

Modułowe sys­te­my to w zasa­dzie zagnież­dżo­ne dwa v‑modele. Najpierw pro­jek­tu­je­my archi­tek­tu­rę cało­ści: powsta­je model kom­po­nen­to­wy. Kolejne eta­py to ite­ra­cyj­ne dostar­cza­nie poszcze­gól­nych kom­po­nen­tów. W kon­struk­cjach elek­tro­me­cha­nicz­nych i tak musi­my cze­kać na ukoń­cze­nie cało­ści (samo­chód czy pral­ka albo jest w cało­ści, albo nie mamy cze­go uży­wać). W przy­pad­ku opro­gra­mo­wa­nia może­my sku­pić sie na poje­dyn­czych komponentach. 

Poprawnie zapro­jek­to­wa­ne opro­gra­mo­wa­nie to samo­dziel­ne usłu­gi apli­ka­cyj­ne. Złożone nie raz, apli­ka­cje powsta­ją jako zbio­ry takich usług, na ryn­ku widzi­my je jako goto­we wie­lo­mo­du­ło­we sys­te­my. Jednak dedy­ko­wa­ne pro­jek­ty nie mają rygo­ru odda­nia w cało­ści”. Usługi apli­ka­cyj­ne mogą być odda­wa­ne jed­na po dru­giej. Wtedy opi­sy­wa­ny tu v‑model to naj­pierw lewa stro­na: tak zwa­na archi­tek­tu­ra wyso­kie­go pozio­mu”, a następ­nie ite­ra­cyj­no-przy­ro­sto­we reali­za­cje kolej­nych kom­po­nen­tów i usług. Każda kolej­na usłu­ga (kom­po­nent) to pro­jek­to­wa­nie, imple­men­ta­cja, testy i odda­nie do użytku.

Podejścia zna­ne jako Use Case 2.0 czy Microservice, to wła­śnie takie modułowe 

Jednak nadal na eta­pie ana­liz i pro­jek­to­wa­nia auto­rzy tych pro­jek­tów bar­dzo czę­sto nadal poprze­sta­ją na opi­su idei, czy­li pro­ce­su biz­ne­so­we­go i nazwa­nych usług, nie jest to jed­nak pro­jek­to­wa­nie sys­te­mu a co naj­wy­żej biz­ne­so­we wyma­ga­nia . V‑model opie­ra się na tym, że imple­men­ta­cja jest poprze­dza­na pro­jek­to­wa­niem, czy­li swo­istym stu­dium wyko­nal­no­ści. Jest to spraw­dzo­na meto­da z każ­dej innej inżynierii: 

zanim zaczniesz budo­wać, upew­nij się, że wiesz co powin­no powstać.

Tak więc v‑model wyglą­da na dobrą meto­dę-pro­ces. To czy jest to wodo­spad czy nie, zale­ży od archi­tek­tu­ry cało­ści (mono­lit czy nie mikro­ser­wi­sy) a nie od fak­tu poprze­dza­nia imple­men­ta­cji projektowaniem.

Źródła

Balaji, S., & Murugaiyan, M. S. (2012). Waterfall vs. V‑Model vs. Agile: A com­pa­ra­ti­ve stu­dy on SDLC. International Journal of Information Technology and Business Management, 2(1), 26 – 30.
Mathur, S., & Malik, S. (2010). Advancements in the V‑Model. International Journal of Computer Applications, 1(12), 29 – 34.
Friman, E. (2020). BUILDING AND ADAPTING SYSML BASED SYSTEM ARCHITECTURE FRAMEWORK FOR MECHATRTONIC SYSTEMS. 75.
Arroyo, J. C. T. (2020). Analysis and Design of Enterprise Resource Planning System for a Coffee Shop. International Journal of Advanced Trends in Computer Science and Engineering, 9(3), 2972 – 2980. https://​doi​.org/​1​0​.​3​0​5​3​4​/​i​j​a​t​c​s​e​/​2​0​2​0​/​7​4​9​3​2​020

Przyczyny nieplanowanych kosztów wdrożeń

Zarządzanie ryzy­kiem to pro­za życia kie­row­ni­ków pro­jek­tów. Z jed­nej stro­ny doświad­czo­ny kie­row­nik pro­jek­tu powi­nien dosko­na­le radzić sobie z ryzy­kiem, z dru­giej zaś stro­ny prak­ty­ka pro­jek­tów poka­zu­je, że efek­ty są nie­ste­ty sła­be bo ok. 90% IT na świe­cie ma prze­kro­co­zne budże­ty i ter­mi­ny .

Jednym z cie­kaw­szych narzę­dzi zarzą­dza­nia ryzy­kiem jest mało popu­lar­ny tak zwa­ny sto­żek nie­pew­no­ści. Ogólna zasa­da pla­no­wa­nia mówi, że im bar­dziej w przy­szłość wybie­ga­ją pro­gno­zy tym bar­dziej są one nie­pew­ne. Jest nie tyl­ko intu­icyj­ne ale i udo­wod­nio­ne mate­ma­tycz­nie. Stożek nie­pew­no­ści to wykres poka­zu­ją­cy zwią­zek pomię­dzy kosz­ta­mi pro­jek­tu a posia­da­ną wie­dzą na eta­pie ini­cja­cji pro­jek­tu np. imple­men­ta­cji (dostar­cze­nia) opro­gra­mo­wa­nia. Poniżej jeden z przy­kła­dów jego zobrazowania:

Stożek nie­pew­no­ści

Stożek ten (sto­żek nie­pew­no­ści) to narzę­dzie empi­rycz­ne (!), obra­zu­je spo­dzie­wa­ne kon­se­kwen­cje jaki­mi są kosz­ty, gene­ro­wa­ne przez nie­pew­ność (przed­wcze­sne, nie­uda­ne pro­to­ty­py, wpro­wa­dza­nie zmian po przed­wcze­snym roz­po­czę­ciu prac imple­men­ta­cyj­nych i wdro­że­nio­wych, itp.). 

Na powyż­szym wykre­sie, czer­wo­na linia obra­zu­je kosz­ty eta­pu prac bez ana­liz i pro­jek­to­wa­nia (agi­le) a zie­lo­na kosz­ty prac poprze­dzo­nych ana­li­za­mi i pro­jek­to­wa­niem. Linie te spo­ty­ka­ją w punk­cie, w któ­rym wie­dza o osta­tecz­nej wer­sji pro­duk­tu jest już taka sama. Punkty ozna­czo­ne dia­men­tem” to kamie­nie milo­we pro­jek­tu. Wartość kosz­tu odnie­sie­nia 1.0 to sytu­acja, w któ­rej w momen­cie roz­po­czę­cia pro­jek­tu nie było­by żad­nych nie­wia­do­mych (ryzy­ko zakre­su pro­jek­tu = zero). Całkowity koszt pro­jek­tu to pola pod krzy­wy­mi (pomię­dzy daną krzy­wą a pozio­mem zero lewej osi). Praktyka poka­zu­je więc, że brak pla­no­wa­nia i pro­jek­to­wa­nia pod­no­si kosz­ty pro­jek­tu śred­nio czterokrotnie.

W przy­pad­ku apli­ka­cji będą­cej mono­li­tem wykres repre­zen­tu­je cały pro­jekt („water fall”, meto­da wodo­spa­do­wa), czy­li pro­jekt trwa­ją­cy nie raz kil­ka lat. Prawdopodobieństwo, że reali­za­cja deta­licz­nie zapla­no­wa­ne­go np. na 5 lat pro­jek­tu będzie wyma­ga­ła korek­ty pla­nów lub wpro­wa­dza­nia zmian do pro­jek­tu, gra­ni­czy obec­nie z pewnością:

W przy­pad­ku zasto­so­wa­nia metod obiek­to­wych, zorien­to­wa­nych na komponenty/mikroserwisy, wykres Stożek nie­pew­no­ści repre­zen­tu­je dostar­cze­nie jed­nej usłu­gi apli­ka­cyj­nej (przy­pa­dek uży­cia, imple­men­to­wa­nej jako kom­po­nent, patrz tak­że ite­ra­cyj­no-przy­ro­sto­we dostar­cza­nie opro­gra­mo­wa­nia jako kolej­nych usług apli­ka­cyj­nych, MVP: Minimum Value Product). Implementacja jed­nej takiej usłu­gi z regu­ły mie­ści się w jed­nym kwar­ta­le. W efek­cie prak­tycz­nie eli­mi­nu­je­my skut­ki nie­pew­no­ści, pla­nu­jąc reali­za­cję pro­jek­tu tak, by żad­ne pla­ny nie wybie­ga­ły zbyt dale­ko w przy­szłość (z regu­ły gra­ni­ca jest rok budże­to­wy). Jest to moż­li­we dzię­ki odej­ściu od mono­li­tycz­nej archi­tek­tu­ry apli­ka­cji. Realizacja pro­jek­tu wytwa­rza­nia apli­ka­cji o kom­po­nen­to­wej (np. mikro­ser­wi­sy) archi­tek­tu­rze wyglą­da jak poniżej:

Warto tu zwró­cić uwa­gę, że apli­ka­cje zbu­do­wa­ne w opar­ciu o jed­ną i cen­tral­ną bazę danych w mode­lu rela­cyj­nym (RDBMS) są wła­śnie typo­wy­mi mono­li­ta­mi, np. więk­szość powszech­nie zna­nych dużych sys­te­mów ERP. Duże sys­te­my rela­cyj­nych baz danych są z tego powo­du od daw­na krytykowane:

(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))

W tym przy­pad­ku ofer­ty (obiet­ni­ce) dostaw­ców tego typu sys­te­mów (mono­li­ty) to zie­lo­na linia na dia­gra­mie Stożek nie­pew­no­ści, a fak­tycz­ne kosz­ty tych wdro­żeń, pole­ga­ją­ce na bie­żą­cej, pro­wa­dzo­nej ad-hoc adap­ta­cji, to linia czer­wo­na, co potwier­dza­ją sta­ty­sty­ki .

Źródła

Little, T. (2006). Schedule esti­ma­tion and uncer­ta­in­ty sur­ro­un­ding the cone of uncer­ta­in­ty. Software, IEEE, 23, 48 – 54. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​0​6​.82
Cook, S., & Daniels, J. (1994). Designing object sys­tems: object-orien­ted model­ling with Syntropy. Prentice Hall.
http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471

Zwinna analiza biznesowa to mit czy fakt?

Agile busi­ness ana­lyst has the capa­bi­li­ty to keep the whe­el rol­ling. They?re a trans­for­ma­ti­ve fun­nel thro­ugh which a requ­ire­ment pas­ses down to the deli­ve­ry path towards an expec­ted out­co­me. This SDLC machi­ne needs con­ti­nu­ous fuel in the form of well-defi­ned and infor­med infor­ma­tion which is pro­vi­ded by an agi­le busi­ness ana­lyst. As long as an agi­le busi­ness ana­lyst does the job, this machi­ne will rema­in on its cour­se to deli­ver gre­ater solutions.Coming to our ori­gi­nal question, is an agi­le busi­ness ana­lyst a myth or a reali­ty? There is a cle­ar answer. It is a reali­ty if an orga­ni­za­tion reali­zes the value, but it is a myth for imma­tu­re orga­ni­za­tions who­se pro­ces­ses are ill-defi­ned and are nowhe­re on a path towards best prac­ti­ces. (Is Agile Business Analyst a Myth or a Reality? )

Tak więc (zwin­ny) ana­li­tyk biz­ne­so­wy to model pra­cy pole­ga­ją­cy na sta­łym dostar­cza­niu (na eta­pie imple­men­ta­cji) kolej­nych infor­ma­cji. Projekt two­rze­nia apli­ka­cji zawsze trwa w cza­sie, więc w toku two­rze­nia opro­gra­mo­wa­nia zmie­nia się biznes. 

Developerzy czę­sto mówią, że klient zmie­nia im wyma­ga­nia, a tak na praw­dę ktoś zbyt wcze­śnie zapi­sał zbyt wie­le szcze­gó­łów. Implementacja dedy­ko­wa­ne­go opro­gra­mo­wa­nia to tak na praw­de pętla ite­ra­cyj­no-przy­ro­sto­wa: zbie­ra­my infor­ma­cje potrzeb­ne do wytwo­rze­nia jed­nej usłu­gi apli­ka­cyj­nej i imple­men­tu­je­my ją, wszel­kie szcze­gó­ły odkła­da­my na ostat­ni moment. Wymaga to jed­nak zmia­ny podej­ścia. Trzy lata temu pisa­łem na tym blogu:

Rynek zmie­nia się szyb­ko, więc nie ma sen­su szcze­gó­ło­we pro­jek­to­wa­nie cze­go­kol­wiek z uwa­gi na czas jaki zaj­mie takie pro­jek­to­wa­nie i ryzy­ko, że taki pro­jekt sta­nie się szyb­ko nie­ak­tu­al­ny. Nikt roz­sąd­ny nie nama­wia dzi­siaj do cze­goś o wdzięcz­nej nazwie ??water­fall?. Co więc zro­bić? Dla dużych pro­jek­tów two­rzy­my archi­tek­tu­rę, opi­su­je­my mecha­ni­zmy dzia­ła­nia, poli­ty­kę roz­bu­do­wy i opis cyklu życia. Czyli to co pozwo­li roz­wi­jać roz­wią­za­nie meto­dą ite­­ra­­cy­j­no-przy­­ro­­sto­­wą, w razie potrze­by pozwo­li na prze­pro­jek­to­wa­nie, ale jako całość nadal będzie spój­ne, nie będzie wyma­ga­ło wymia­ny cało­ści gdy zmie­nią się warun­ki na ryn­ku.Można w tym miej­scu zary­zy­ko­wać tezę, że nie ma cze­goś takie­go jak ??inży­nie­ria wyma­gań? bo czym ona jest i co jest jej pro­duk­tem? Uporządkowany spis życzeń? Mamy nato­miast na pew­no ??inży­nie­rię sys­te­mów?.? sys­te­ma­mi są orga­ni­za­cje a tak­że narzę­dzia jakich uży­wa­ją np. opro­gra­mo­wa­nie? (Wymagania umar­ły. Rozwiązaniem jest cykl życia pro­duk­tu | | Jarosław Żeliński IT-Consulting)

Z cze­go nale­ży więc od razu zre­zy­gno­wać? Z opra­co­wa­nia rela­cyj­ne­go mode­lu (bazy) danych dla całej apli­ka­cji, i prze­sta­wić sie na idee mikro-ser­wi­sów, czy­li uzna­nia, że apli­ka­cja nie jest mono­li­tem a zesta­wem kom­po­nen­tów reali­zu­ją­cych usłu­gi apli­ka­cyj­ne. Usługi apli­ka­cyj­ne mode­lu­je­my jako Przypadki Użycia (nota­cja UML) i to sta­no­wi kon­takt z dostaw­cą. Jednak czar­na skrzyn­ka” (opis nie zawie­ra­ją­cy mecha­ni­zmu dzia­ła­nia) jest bar­dzo ryzy­kow­ny, dla­te­go sku­tecz­ne meto­dy doku­men­to­wa­nia wyma­gań, to meto­dy zorien­to­wa­nie na mode­le (MDA) opi­su­ją­ce logi­kę dzia­ła­nia sys­te­mu (model jako wyma­ga­nie), a zamiast two­rze­nia kor­po­ra­cyj­ne­go rela­cyj­ne­go mode­lu danych, zamy­ka­my się w doku­men­tach jako ele­men­tar­nych nośni­kach danych (i nie boimy sie redun­dan­cji danych w całym sys­te­mie). Ogromne i szcze­gó­ło­we doku­men­ty i mode­le są wyłącz­nie stra­tą cza­su i pieniędzy:

(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))
(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))

Dlatego od lat fascy­nu­je mnie nie­kon­se­kwen­cja wie­lu deve­lo­pe­rów: naj­pierw wie­sza­ją psy na meto­dach nazy­wa­nych water­fall”, a już chwi­lę potem zaczy­na­ją pro­jek­to­wa­nie jed­ne­go rela­cyj­ne­go mode­lu danych dla całe­go projektu! 

Zwinny Analityk Biznesowy utrzy­mu­je pętlę ite­ra­cji przy­ro­stu zakre­su pro­jek­tu: mając opra­co­wa­ną archi­tek­tu­rę cało­ści i para­dyg­mat (poli­ty­kę) pro­jek­to­wa­nia (np. obiek­to­wy), dostar­cza cyklicz­nie i zawsze na ostat­ni moment, kolej­ne szcze­gó­ły, bo wte­dy ma naj­więk­szą wie­dzę, i ryzy­ko zmia­ny zakre­su jest naj­mniej­sze. To się nazy­wa «nad­zór autorski».

Tak więc klu­czem do suk­ce­su, w dzi­siej­szych warun­kach, jest model opar­ty na kom­po­nen­to­wej archi­tek­tu­rze i ite­ra­cyj­nym dostar­cza­niu kolej­nych usług apli­ka­cyj­nych . Jak? Analiza, pro­jek­to­wa­nie i implementacja:

  • Analiza biz­ne­so­wa (pro­ce­sy biz­ne­so­we) i sys­te­mu infor­ma­cji w orga­ni­za­cji, i decy­zja o ewen­tu­al­nej stan­da­ry­za­cji doku­men­tów i pro­ce­sów. (nota­cje BMM, SBVR, BPMN, UML)
  • Opracowanie mode­lu infor­ma­cyj­ne­go czy­li sza­blo­nów doku­men­tów, ich wza­jem­nych powią­zań i słow­ni­ka pojęć. (nota­cja UML, SBVR)
  • Opracowaniu archi­tek­tu­ry cało­ści i opi­sa­nie cyklu życia pro­jek­tu (nota­cja UML).
  • Przejścia do fazy imple­men­ta­cji z nad­zo­rem autor­skim auto­ra pro­jek­tu (zarzą­dza­nie zmia­ną, sta­ła aktu­ali­za­cja doku­men­ta­cji systemu).

Pierwsze przy punk­ty, ich reali­za­cja, nie powin­ny nigdy trwać dużej niż kwar­tał, a doku­men­ta­cja pier­wot­na raczej nie powin­na prze­kro­czyć nigdy 100 stron, bez wzglę­dy na wiel­kość pro­jek­tu! Im więk­szy pro­jekt tym bar­dziej doku­men­ta­cja począt­ko­wa powin­na być abs­trak­cyj­nym mode­lem. Innymi sło­wy: im więk­szy i dłu­żej trwa­ją­cy pro­jekt, tym bar­dziej jego opis powi­nien być stra­te­gią jego reali­za­cji, a nie taktyką. 

Czy zwin­ny ana­li­tyk biz­ne­so­wy jest mitem czy rze­czy­wi­sto­ścią? Istnieje jasna odpo­wiedź: to rze­czy­wi­stość, jeśli orga­ni­za­cja zda­je sobie spra­wę z war­to­ści takiej pra­cy, ale jest mitem dla nie­doj­rza­łych orga­ni­za­cji, któ­rych pro­ce­sy są źle zdefiniowane.

Źródła

Steve Burbeck (2012) How to use Model-View-Controller (MVC). Available at: https://web.archive.org/web/20120729161926/http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html (Accessed: 5 January 2020).
Jenney, J. et al. (2010) Modern methods of sys­tems engi­ne­ering: with an intro­duc­tion to pat­tern and model based methods. Erscheinungsort nicht ermit­tel­bar: Joe Jenney.
Awaysheh, F.M. et al. (2019) Next-Generation Big Data Federation Access Control: A Reference Model’, arXiv:1912.11588 [cs] [Preprint]. Available at: http://​arxiv​.org/​a​b​s​/​1​9​1​2​.​1​1​588 (Accessed: 4 January 2020).
Garland, J. and Anthony, R. (2003) Large-sca­le softwa­re archi­tec­tu­re: a prac­ti­cal guide using UML. Chichester ; New York: J. Wiley.
Kumar, R.N.P. and Patil, S. (2019) A System and Method for impro­ving the Model Based Systems Engineering Environment capa­bi­li­ty’, INCOSE International Symposium, 29(S1), pp. 277 – 290. http://​doi​.org/​1​0​.​1​0​0​2​/​j​.​2​334 – 5837.2019.00685.x.

Visual Paradigm: Online Drawing

Visual-Paradigm wraz z wer­sją 15 po cichut­ku” wpro­wa­dził nowe narzę­dzie inte­gru­ją­ce pra­ce ana­li­ty­ka i klien­ta: dia­gra­my on-line w prze­glą­dar­ce. Aplikacja ta jest zin­te­gro­wa­na z ser­we­rem VPository i PostMania co daje nie­sa­mo­wi­te moż­li­wo­ści: ana­li­tyk może dać klien­to­wi do ręki narzę­dzie pozwa­la­ją­ce two­rze­nie infor­ma­cji w posta­ci gra­ficz­nej. Tak powsta­łe dia­gra­my są w locie wsta­wia­nie do narzę­dzia CASE.

Do tej pory dia­log z fir­mą ana­li­zo­wa­ną pole­gał na prze­sy­ła­niu ana­li­ty­ko­wi opi­sów wyko­ny­wa­nych edy­to­rem tek­sty, cza­sem arku­szem kal­ku­la­cyj­nym, pro­gra­mem do pre­zen­ta­cji itp. Analityk musiał je prze­pi­sać lub prze­ry­so­wać. Teraz, gdy tyl­ko jakąś treść moż­na opi­sać jakim­kol­wiek sche­ma­tem blo­ko­wym, dia­gra­mem, nawet nie­for­mal­nym (czy­li łatwiej­szym do przy­go­to­wa­nia przez klien­ta), jest to moż­li­we on line, pod nad­zo­rem analityka.

Jest kolej­ny ele­ment roz­sze­rza­ją­cy kata­log narzę­dzi on-line pakie­tu Visual-Paradigm:

Oprócz już ist­nie­ją­cych narzę­dzi on-line: Agile (user sto­ry, bac­klog, itp.), tabli­cy Customer Journey Mapping, task­me­ne­dże­ra Tasifier i Postmanii mamy narzę­dzie do two­rze­nia dia­gra­mów i współ­dzie­le­nia ich w zespo­le analityków.

Source: Visual Paradigm: Online Drawing Tool, Story Map, Journey Map

Visual Paradigm 15.0 Released

Dzisiejszej nocy opu­bli­ko­wa­no wer­sję 15 pakie­tu CASE Visua-Paradigm. Producent tego opro­gra­mo­wa­nia kon­se­kwent­nie pnie się na szczyt roz­wią­zań CASE w swo­jej kla­sie, a jako obser­wa­tor i użyt­kow­nik powiem tak: stra­te­gia jest pro­sta czy­li apli­ka­cja dla ana­li­ty­ka, pro­jek­tan­ta i archi­tek­ta ma udo­stęp­niać naj­wyż­szej kla­sy narzę­dzia do pra­cy ze stan­dar­do­wy­mi nota­cja­mi i zgod­nie z ich spe­cy­fi­ka­cja­mi, wspie­rać poję­cio­we i logicz­ne śla­do­wa­nie pomię­dzy mode­la­mi, w niczym nie ogra­ni­czać ana­li­ty­ka (nie narzu­cać żad­nej meto­dy­ki postę­po­wa­nia), dać narzę­dzia do pra­cy na eta­pie nie­for­mal­nym, wspie­rać cały pro­ces MDA jaki zwin­ne meto­dy pra­cy, i co naj­waż­niej­sze: dać narzę­dzie do komu­ni­ka­cji pomię­dzy uczest­ni­ka­mi projektu.

I taki jest Visual od lat, kolej­ne 15. wcie­le­nie, to jesz­cze wię­cej inte­gra­cji i jesz­cze wię­cej komunikacji:

Feb 27, 2018 – Visual Paradigm International Limited anno­un­ced today the rele­ase of Visual Paradigm 15.0.

Visual Paradigm 15.0 intro­du­ces a num­ber of new featu­res, which includes:

  • Wireflow Diagram
  • Animating paths in Wireflow Diagram
  • STEPS – Efficient design and ana­ly­sis with pre­scri­bed wizards
  • Visual API desi­gner for Swagger-based RESTful API
  • Swagger-based RESTful API generation
  • Visual API desi­gner for API-Blueprint for­mat­ted RESTful API
  • API-Blueprint for­mat­ted RESTful API generation
  • [VP Online] New dia­gram: ER Diagram
  • [VP Online] New dia­gram: Organization Chart
  • [VP Online] New dia­gram: Mind Map
  • [VP Online] New dia­gram: DFD
  • [VP Online] New dia­gram: Venn Diagram
  • [VP Online] New dia­gram: Floor Plan
  • [VP Online] Google Drive integration
  • [VP Online] Real-time syn­chro­ni­za­tion of diagrams
  • [VP Online] Multilingual support
  • [VP Online] Visio dra­wing import
  • [VP Online] Multi-pages support

Enhancements to Visual Paradigm 15.0 includes:

  • Upgraded Hibernate ver­sion to 5.1
  • Improved sta­bi­li­ty in High DPI environments
  • Refined data for­war­ding mecha­nism for TOGAF ADM
  • Supported hiding inter­fa­ce cap­tion in ArchiMate diagram
  • Supported impor­ting sty­les for gene­ra­te deliverables
  • Supported apply­ing Shape Legend on connectors
  • Supported adding one sha­pe to mul­ti­ple layers
  • Supported sen­ding sha­pes from Business Concept Diagram to backlog
  • Supported display­ing para­me­ter of entry/exit/do acti­vi­ty on State Machine Diagram
  • Supported ente­ring seve­ral deli­ve­ra­ble pro­per­ties as variables
  • Introduced new user per­mis­sion option to con­trol who can uplo­ad Just-in-Time Work Items to repository
  • Improved Traditional Chinese support

Source: Visual Paradigm 15.0 Released – ChangeLog – Discuss the Visual Paradigm