Czym sie różnią wymagania wobec rozwiązania od potrzeb użytkownika?

Wstęp

Siedem lat temu (2015) arty­kuł o wyma­ga­niach i śla­do­wa­niu koń­czy­łem słowami: 

Tak więc wyma­gań biz­ne­so­wych może być kil­ka­dzie­siąt. Wymaganych usług sys­te­mu (przy­pad­ków uży­cia) w dużym pro­jek­cie tak­że może być kil­ka­dzie­siąt. Ale set­ki, czy tysią­ce ??wyma­gań? to wyraz utra­ty pano­wa­nia nad zakre­sem pro­jek­tu? Tu zwró­cę uwa­gę, że wyma­ga­niem (usłu­ga sys­te­mu) może być np. wytwo­rzo­na fak­tu­ra VAT zgod­na z prze­pi­sa­mi. Cechy tej fak­tu­ry (lista pól) to nie osob­ne wyma­ga­nia, to cechy (para­me­try, atry­bu­ty) jed­ne­go wyma­ga­nia. Żadna cecha fak­tu­ry VAT nie ma sama w poje­dyn­kę żad­nej war­to­ści, nie może więc być oddziel­nym przy­pad­kiem uży­cia, tak samo jak wyma­ga­niem naszym może być samo­chód, ale jego kolor czy auto­ma­tycz­na skrzy­nia bie­gów, to cechy samo­cho­du, nie ma sen­su wyma­gać ??czer­wo­ne­go kolo­ru? nie ocze­ku­jąc samo­cho­du (i jak uza­sad­nić, to że ten kolor wspie­ra cel biz­ne­so­wy). Przypadkiem uży­cia samo­cho­du jest podróż a nie wło­że­nie klu­czy­ka do sta­cyj­ki, bo to jest tyl­ko jeden z ele­men­tów sce­na­riu­sza roz­po­czę­cia podró­ży samochodem.

Source: Dlaczego śla­do­wa­nie wyma­gań jest istot­ne w pro­jek­cie? – Jarosław Żeliński IT-Consulting

Nadal poja­wia­ją się publi­ka­cje o wyma­ga­niach, zarzą­dza­niu nimi i reali­zo­wa­niu ich. Na ryn­ku są dostęp­ne apli­ka­cje pozwa­la­ją­ce je kolek­cjo­no­wać i zarzą­dzać taką kolek­cją. I sta­le mamy do czy­nie­nia z ich – wyma­gań – nie­jed­no­znacz­no­ścią . Okazuje się, że ich zna­cze­nie sta­je sie klu­czo­we dla pro­jek­tów, tak­że z per­spek­ty­wy pra­wa (PZP i zde­fi­nio­wa­ne w zale­ce­niach UZP poję­cie potrze­ba). Tym razem sku­pię się na poję­ciach «wyma­ga­nie» i «potrze­ba» w odnie­sie­niu do pro­jek­tu rozwiązania.

(wię­cej…)

Czytaj dalejCzym sie różnią wymagania wobec rozwiązania od potrzeb użytkownika?

Czym są testy oraz kto i co testuje

Robię to zawsze a najrzadziej o tym pisze, bo to "takie oczywiste", a co to takiego? TESTY. Dobrze opracowane testy to ciekawa i wyrafinowana forma sprawdzania tego czy dostajemy to co chcemy dostać, to za co płacimy (nie raz słono). Czym są (powinny być) kryteria akceptacji? To właśnie wymagania, pozostaje pytanie: Które? Jeżeli to będą pierwotne wymagania biznesowe jest źle (patrz: Przypadki użycia to nie wymagania). Wiec co? Wymaganiem jest model: zamawiana konstrukcja, mechanizm działania. V-model czyli wprowadzenie Ogólnym, najczęściej przytaczanym modelem opisującym cykl wytwarzania w inżynierii jest tak zwany…

Czytaj dalejCzym są testy oraz kto i co testuje

Normy i zgodność z nimi

Normy ISO, bo o nich będę tu pisał, to przedmiot wielu kontrowersji: zwolennicy i audytorzy namawiają, reszta zaleca rozwagę. Czym są Normy W kontekście norm ISO, słownikowa definicja normy brzmi: norma ?ustalona, ogólnie przyjęta zasada? (https://sjp.pwn.pl/szukaj/norma.html) Normami nazywamy także zbiory zasad. Dla porządku będę używał słowa norma pisanego z małej litery w ogólnym słownikowym znaczeniu (zasada), oraz w formie Norma, pisanego z dużej litery, w rozumieniu tekstu (produktu) komitetu normalizacyjnego. Generalnie stosowanie Norm jest dobrowolne: CZY STOSOWANIE NORM JEST OBOWIĄZKOWE?Nie. Od 1 stycznia 2003 r. nowa Ustawa o normalizacji zniosła…

Czytaj dalejNormy i zgodność z nimi
Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]
Booch, G. (1994). Object-oriented Analysis and Design with Applications. 2nd Edition, the Benjamin/Cummings Publishing Company, Inc.

Wymagania biznesowe – jak zbierać i dokumentować

Wprowadzenie Ronald Ross, współautor standardu modelowania reguł biznesowych i biznesowego słownika pojęć napisał niedawno na swoim profilu LinkedIn: "People love stories. Are user stories helpful in engineering business solutions? Absolutely. Are you done with requirements and solution engineering when you?ve worked through a set of user stories? No. Not even close!" ["Ludzie kochają historie. Czy historie użytkowników są pomocne w tworzeniu rozwiązań biznesowych? Zdecydowanie tak. Czy skończyłeś z wymaganiami i inżynierią rozwiązania, gdy już opracowałeś zestaw historyjek użytkownika? Nie. Nawet nie zbliżyłeś się do nich!".] (https://www.linkedin.com/posts/rossronald_people-love-stories-are-user-stories-helpful-activity-6935627008265633793-Bpzb/) Świat od dekad boryka…

Czytaj dalejWymagania biznesowe – jak zbierać i dokumentować

Analiza efektywności i kosztów czyli symulacja procesu

Wstęp

Produktem mode­lo­wa­nia pro­ce­sów biz­ne­so­wych są jakieś dia­gra­my, i z tym jeste­śmy oswo­je­ni. Od cza­su do cza­su moż­na usły­szeć o symu­la­cjach pro­ce­sów, lecz to już jed­nak znacz­nie rza­dziej. O symu­la­cjach pro­ce­sów pisze się mniej: Google Scholar (lite­ra­tu­ra nauko­wa) poka­zu­je ok. 5 mln publi­ka­cji na temat mode­lo­wa­nia pro­ce­sów biz­ne­so­wych, na temat ich symu­la­cji 2 mln mniej. Ale już Google („cały Internet”) odpo­wied­nio: 2,3 mld. i 282 mln. Jak widać w powszech­nym obie­gu symu­la­cje, jako temat, to trzy rzę­dy (tysiąc­krot­nie) mniej­sza ilość tek­stów! (wyszu­ki­wa­ne były hasła ang. «busi­ness pro­cess mode­ling» oraz «busi­ness pro­cess simu­la­tion»). Zastanówmy się dla­cze­go i co moż­na osią­gnąć symulacją.

(wię­cej…)

Czytaj dalejAnaliza efektywności i kosztów czyli symulacja procesu

Odpowiedzialność administratora systemu

Wstęp

pra­wie 10 lat temu pisałem:

Często spo­ty­kam się z róż­ny­mi meto­da­mi uwzględ­nia­nia pra­wa w doku­men­ta­cji wyma­gań. Jakim wyma­ga­niem jest zgod­ność z obo­wią­zu­ją­cym pra­wem? I trud­niej­sze pyta­nie: czy zmia­na pra­wa to zmia­na wyma­gań? Inny aspekt pro­ble­mu to ana­li­za i defi­ni­cja (opis) tej zgod­no­ści z pra­wem. Spotkać moż­na się z meto­dą pole­ga­ją­cą na trak­to­wa­niu każ­de­go (mają­ce­go wpływ na sys­tem) para­gra­fu np. usta­wy jako wyma­ga­nia. Problem zgod­no­ści opro­gra­mo­wa­nia z pra­wem ma dwa aspek­ty. Zgodność opro­gra­mo­wa­nia z pra­wem pole­ga na tym, że ??opro­gra­mo­wa­nie nie może ogra­ni­czać sto­so­wa­nia pra­wa to jest nie może wymu­szać swo­imi ogra­ni­cze­nia­mi dzia­łań nie­zgod­nych z pra­wem?. Ja oso­bi­ście reko­men­du­ję roz­cią­gnię­cie tej defi­ni­cji na ??ani nie powin­no pozwa­lać na łama­nie pra­wa?. Tu jed­nak wie­lu uwa­ża, że ??zama­wiam narzę­dzie i uży­wam jak chcę, na swo­ja odpo­wie­dzial­ność?. Coś w tym jest, war­to jed­nak zosta­wić ??włącz­nik?. (źr.: Prawo a wyma­ga­nia … )

Dzisiaj czy­tam:

To admi­ni­stra­tor odpo­wia­da za zabez­pie­cze­nia sys­te­mów, a więc tak­że za to, że pra­cow­nik zdo­łał sko­pio­wać dane oso­bo­we na zewnętrz­ny nośnik. […] W oce­nie WSA w toku postę­po­wa­nia PUODO pra­wi­dło­wo usta­lił, iż w SGGW dopusz­czo­no się licz­nych uchy­bień, w szcze­gól­no­ści nie prze­pro­wa­dzo­no wła­ści­wej ana­li­zy ryzy­ka i oce­ny zagro­żeń już na eta­pie pro­jek­to­wa­nia sys­te­mów (pri­va­cy by design) oraz nie wdro­żo­no odpo­wied­nich środ­ków zapew­nia­ją­cych bez­pie­czeń­stwo danych, w tym przed moż­li­wo­ścią wyeks­por­to­wa­nia danych z sys­te­mu na zewnątrz.(źr.: Odpowiedzialność admi­ni­stra­to­ra za naru­sze­nie zasa­dy pri­va­cy by design)

Rzecz w tym, że admi­ni­stra­tor, w rozu­mie­niu pra­wa, to tak­że pod­miot zle­ca­ją­cy powsta­nie opro­gra­mo­wa­nia, któ­re go wspie­ra w reali­za­cji jego obo­wiąz­ków, a jed­nym z tych obo­wiąz­ków jest egze­kwo­wa­nie usta­lo­nych zasad. Dzisiaj o tym, że zbie­ra­nie pod­pi­sów pod oświad­cze­nia­mi” to nie jest bezpieczeństwo. 

(wię­cej…)

Czytaj dalejOdpowiedzialność administratora systemu

Architektoniczne wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

Wprowadzenie

W arty­ku­le o apli­ka­cjach webo­wych, ponad rok temu, pisałem:

Generalnie klu­czo­wą cechą micro-ser­wi­­sów, czy­nią­cą z nich tak zwa­ną zwin­ną archi­tek­tu­rę, jest cał­ko­wi­ta wza­jem­na nie­za­leż­ność imple­men­ta­cji poszcze­gól­nych usług apli­ka­cyj­nych. (źr.: Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych).

Przy innej oka­zji pisa­łem o wzorcach:

Wzorce pro­jek­to­we to bar­dzo waż­na część ??zawo­du? ana­li­ty­ka i archi­tek­ta opro­gra­mo­wa­nia. […] Generalnie wzor­ce są to ska­ta­lo­go­wa­ne stan­dar­dy i dobre prak­ty­ki . (Obiektowe wzor­ce projektowe ) 

Szkolenia dla ana­li­ty­ków poprze­dzam ankie­ta­mi przed szko­le­nio­wy­mi, jak do tej pory żad­na nie zawie­ra­ła pytań o wzor­ce pro­jek­to­we: ani tego że są uży­wa­ne ani tego, że są celem szko­le­nia, nie­mal­że każ­dy dekla­ru­je albo, że uży­wa UML lub, że chce zacząć uży­wać UML, nawet gdy są to pro­gra­mi­ści. Zauważyłem, że wzor­ce pro­jek­to­we w świa­do­mo­ści ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia (OOAD) nie ist­nie­ją”. Wśród pro­gra­mi­stów, jeże­li jest spo­ty­ka­na, to wie­dza o wzor­cach przy­dat­nych w two­rze­niu biblio­tek i narzę­dzi, czę­sto też powie­la­ne są wyuczo­ne sta­re i złe prak­ty­ki pro­gra­mi­stycz­ne rodem z lat 60-tych (np. prak­ty­ki SmallTalk, patrz dalej). 

Z dru­giej stro­ny od wie­lu lat zna­ne są tech­ni­ki MDA (Model Driven Architecture) czy MBSE (Model Based System Engineering), któ­re w róż­nych for­mach, ale jed­nak wska­zu­ją, że naj­sku­tecz­niej­sza for­ma wyra­ża­nia wyma­gań wobec roz­wią­za­nia to pro­jekt archi­tek­tu­ry i logi­ki dzie­dzi­no­wej (model) dzia­ła­nia apli­ka­cji . O pro­jek­to­wa­niu poprze­dza­ją­cym imple­men­ta­cję pisze sie od dość daw­na, meto­dy obiek­to­we i dobre prak­ty­ki zna­ne są od lat .

Autorzy BABoK prak­tycz­nie od począt­ku ist­nie­nia tego wydaw­nic­twa, zwra­ca­ją uwa­gę na tak zwa­ną bia­łą skrzyn­kę”, czy­li wyma­ga­nia wyra­żo­ne w posta­ci wewnętrz­nej struk­tu­ry pro­duk­tu, wska­zu­jąc, że to znacz­nie sku­tecz­niej­sza meto­da defi­nio­wa­nia wyma­gań wobec roz­wią­za­nia, niż tak zwa­na czar­na skrzyn­ka”, czy­li tra­dy­cyj­ne, i jed­nak mniej sku­tecz­ne, wyma­ga­nia wyra­żo­ne tyl­ko jako cechy funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Pamiętajmy, że adre­sa­tem wyma­gań jest zawsze dostaw­ca produktu!

(wię­cej…)

Czytaj dalejArchitektoniczne wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

Modele as-is i to-be, czy warto je robić?

Z zamiarem napisania tego tekstu noszę się już od kilku lat i za każdym razem mówiłem sobie: "ok, jeszcze tylko skończę ten jeden projekt i zobaczymy czy faktycznie ma to sens". I tak od kilku lat. W końcu jednak udało się. Wprowadzenie Popularność podejścia do modeli procesów biznesowych, polegającego na "pokazaniu różnicy", trwa od czasów popularyzacji re-inżynierii procesów biznesowych (lata 90-te) . Umowy na usługi, zawierające w zakresie opracowanie modelu 'as-is' i 'to-be' nadal są podpisywane. Zakładam, że decyzje o zakresie projektu to indywidualne potrzeby zamawiających. Ja opiszę swoje doświadczenia…

Czytaj dalejModele as-is i to-be, czy warto je robić?

Analiza nie musi być przedwdrożeniowa

Wprowadzenie

W ramach jed­ne­go z moich nie­daw­nych pro­jek­tów badaw­czych celem ana­li­zy nie było opra­co­wa­nie wyma­gań na opro­gra­mo­wa­nie (tego typu pro­jek­ty to naj­wy­żej ok. 70% mojej aktyw­no­ści) a roz­wią­za­nie pew­nych pro­ble­mów infor­ma­cyj­nych. Z uwa­gi na ochro­nę know-how klien­ta, opis ten został moc­no okro­jo­ny do isto­ty pro­ble­mu oraz meto­dy jego roz­wią­za­nia, nie ma tu z oczy­wi­stych powo­dów opi­su roz­wią­za­nia (ale waż­ne jest to, że roz­wią­za­nie zna­le­zio­no). Wartość jed­nak ma to, że czy­tel­nik może się tu odna­leźć i sam prze­ko­nać, co jest źró­dłem pew­nych pro­ble­mów, czy i jak moż­na je rozwiązać. 

W poniż­szym tek­ście poję­cie sys­tem odno­si sie do sys­te­mu doku­men­tów i for­mu­la­rzy czy­li do infor­ma­cji i zarzą­dza­nia nią. 

(wię­cej…)

Czytaj dalejAnaliza nie musi być przedwdrożeniowa

Pokłosie webinarium MAP IT

15 Maja 2020 odbyło się ciekawe wirtualne spotkanie (zapowiedzi). Zarejestrowało sie ponad 1200 osób, ponad połowa tej liczby brała faktycznie udział. To oznacza, że mają sens zapowiadane i poruszone tam tematy. O konferencji Konferencja MAP IT ? Management, Analiza i Produkt w IT zorganizowana została przez Hannę Wesołowską z analiza IT. Ogromne ukłony dla Eleny Zhukovej, Olgi Springer z Product Vision oraz pozostałych znakomitych prelegentów ? Jarka Łojewskiego z Fundacji Dobra Porażka, Michała Bartyzela oraz Michała Redy i Mateusza Kapicy z Product Vision. Ostatnim referatem był mój referat o formalizmach w analizie i projektowaniu. Zainteresowanie spotkaniem przeszło…

Czytaj dalejPokłosie webinarium MAP IT

Psychologia podzielona czyli analiza prawdziwa a potoczna

Profesor Łukaszewski swego czasu opublikował bardzo ciekawy tekst: "Psychologia podzielona" . Publikacja ta to porównanie metod, autor pisze we wstępie: W historii psychologii, choć jest to historia krótka, wiele było szkół, systemów teoretycznych, zwalczających się orientacji, piewców jedynej słusznej drogi. Nie o przeszłości jednak zamierzam pisać, tylko o funkcjonujących współcześnie, w pewnej izolacji od siebie, ale w jakiś sposób na siebie wpływających trzech odmian psychologii. Pierwsza, to psychologia rozumiana jako praktyka społeczna, druga ? to psychologia potoczna (ludowa, domowa, zdroworozsądkowa, bo wiele nosi ona nazw) i wreszcie trzecia, to psychologia…

Czytaj dalejPsychologia podzielona czyli analiza prawdziwa a potoczna

Generalizacja/Specjalizacja Przypadków Użycia

W artykule Ile przypadków użycia opisałem przypadki użycia jako narzędzie definiowania zakresu projektu, czyli sposób dokumentowania wymagań. Takie jego zastosowanie jest zdefiniowane w specyfikacji UML . Tym razem chcę ostrzec przed bezkrytycznym "uczeniem się" ze stron internetowych, nawet tych uznawanych powszechnie za "dobre i popularne". Sam niektóre z nich polecam, ale coraz częściej, nie całe serwisy jako takie, a tylko określone artykuły. Modernanalyst.com też do nich należy. Dziś będzie to artykuł, którego nie polecam, a opiszę go, bo autor powiela w nim dość powszechne błędy notacyjne, błędy które stały się…

Czytaj dalejGeneralizacja/Specjalizacja Przypadków Użycia

Koniec treści

Nie ma więcej stron do załadowania