Koncepcja to nie wymagania!

Requirements must be based on facts and real-life sce­na­rios.” (wyma­ga­nia muszą być opar­te na fak­tach i real­nych sce­na­riu­szach). Więc ile war­te są wizje w pro­jek­tach agi­le albo wydu­ma­ne w toku warsz­ta­to­wych burz mózgów lita­nie życzeń i pomy­słów? Nie tyl­ko moim zda­niem: nie są wie­le war­te i nie powin­ny być wymaganiami.

Czytaj dalej Koncepcja to nie wymagania!

TDD – czy same testy to wymagania?

Na niedawno zakończonej konferencji beIT organizowanej na Politechnice Gdańskiej przez Wydział Elektrotechniki, Telekomunikacji i Informatyki, wygłosiłem referat zatytułowany Filozofia czyli Aplikacja jako element biznesowej rzeczywistości (a nie gra komputerowa). Przesłanie tej prezentacji…

Czytaj dalej TDD – czy same testy to wymagania?

Wymagania ? Zarządzanie wersjami

Pomijając ich warianty, stosowane są dwie metody (grupy metod) dokumentowania wymagań i zarządzania nimi. Zakładamy, że są to wymagania wobec produktu (rozwiązania) jaki ma dostarczyć jego dostawca. W BABoK (Business Analysis…

Czytaj dalej Wymagania ? Zarządzanie wersjami

Nieprzewidywalne wymagania

Właśnie, jak to jest? Regularnie słyszę z ust zwolenników stosowania metody, którą nazywają "zwinną", że "nie da się opisać wymagań przed rozpoczęciem projektu, należy/można je [wymagania] odkrywać w toku projektu,…

Czytaj dalej Nieprzewidywalne wymagania

Wymagania pozafunkcjonalne – integracja

Integracja to jeden z trud­niej­szych pro­ble­mów. Wymaga bowiem nie tyl­ko spe­cy­fi­ko­wa­nia (i potem ich imple­men­to­wa­nia) inter­fej­sów, ale tak­że ana­li­zy i opra­co­wa­nia bez­piecz­nej archi­tek­tu­ry całe­go sys­te­mu (tu zno­wu archi­tek­tu­ra kor­po­ra­cyj­na). Wiele firm ma, nie dwie ale kil­ka, kil­ka­na­ście a nie­któ­re nawet set­ki apli­ka­cji. Jeżeli będę ze sobą pospa­wa­ne” wywo­ła­nia­mi SQL/ODBC, to rusze­nie tego” prak­tycz­nie zawsze koń­czy się kra­chem (czy­taj ogrom­ne kosz­ty przy­wró­ce­nia funk­cjo­no­wa­nia cało­ści). Brak prze­my­śla­nej archi­tek­tu­ry, inte­gra­cja ad-hoc każ­dy z każ­dym”, to pro­sta dro­ga do kło­po­tów i ogrom­nych kosz­tów utrzy­ma­nia cało­ści. Stosowanie API (ich two­rze­nie) nie­co tyl­ko pod­no­si kosz­ty wdro­że­nia, za to chro­ni przed bar­dzo duży­mi, nie­pla­no­wa­ny­mi, wydat­ka­mi w przyszłości.

Czytaj dalej Wymagania pozafunkcjonalne – integracja

Wymagania pozafunkcjonane czyli jaka architektura

Jak wspo­mnia­łem, wie­lu dostaw­ców opro­gra­mo­wa­nia jak Rejtan, bro­ni się przed ujaw­nia­niem archi­tek­tu­ry, swo­ich pro­duk­tów. Głównym powo­dem jest zapo­bie­ga­nie przed­wcze­sne­go wyja­wie­nia opi­sa­nych wyżej wad sys­te­mów z gru­bym klien­tem (znacz­nie rza­dziej spek­ta­ku­lar­ny pomysł, w koń­cu mamy jed­nak jakieś stan­dar­dy). Przypadki, w któ­rych zakup sys­te­mu był rela­tyw­nie niski ale koszt utrzy­ma­nia, roz­wo­ju i dosto­so­wa­nia nie raz wręcz ogrom­ny, to z regu­ły wła­śnie zakup sys­te­mu w tej kosz­tow­nej architekturze.
Jak sta­rać się tego uni­kać? Na eta­pie defi­nio­wa­nia wyma­gań poza-funk­cjo­nal­nych, żądać takich cech jak opi­sa­ne powy­żej czy­li wła­snie: dostęp do cało­ści przez prze­glą­dar­kę WWW, niskie wyma­ga­nia na łącza przy zdal­nej pra­cy i pra­cy w sie­ci roz­pro­szo­nej tery­to­rial­nie, oddzie­le­nie kom­po­nen­tu z wła­sną dedy­ko­wa­ną logi­ką biznesową.

Czytaj dalej Wymagania pozafunkcjonane czyli jaka architektura

Zarządzanie wymaganiami

Z powyż­sze­go pły­nie tak­że kolej­ny wnio­sek: autor spe­cy­fi­ka­cji wyma­gań, powi­nien kon­ty­nu­ować pro­jekt jako oso­ba zarzą­dza­ją­ca wyma­ga­nia­mi, i bar­dzo dobrze jest jeże­li pra­cu­je po stro­nie Zamawiającego, gdyż sta­no­wi natu­ral­ny mecha­nizm kon­tro­li pra­cy dostaw­cy np. opro­gra­mo­wa­nia. Zamawiający nie ma innej moż­li­wo­ści real­ne­go, mery­to­rycz­ne­go nad­zo­ru nad dostaw­cą, to Zamawiający powi­nien zarzą­dzać wyma­ga­nia­mi bo to w koń­cu jego wymagania!

Czytaj dalej Zarządzanie wymaganiami