czwartek, 31 lipca 2014

Tejemnica Inżynierii Wymagań

Do ITWIZ dostarczyłem artykuł, tutaj jego motto:

Motto:

„A któż to widział, żeby komissye i doktorzy hab. cich., i uczone ekspertyzy, i rewidenci, i kontrrewidenci, i mikroskopy na kopy, a nikt nic, ni pary z gęby, jeno w kucki a w kucki? To ja tu teraz powiadam Veto, Grólu Zbawnucy, i Veto, panowie bracia, i Veto, czyli nie masz zgody na ciebie, Kąciarzu Bezecny, i póki ciebie, tedy tu g… będzie, nie Harmonia Sfer!!!” [1].


środa, 30 lipca 2014

Dziękuję, Quale!


W ramach korekty złożonego do Quale artykułu, dostałem od nich parę bardzo fajnych linków, podważających moją tezę, że "ale brak jest jakichkolwiek systematycznych (nie anegdotycznych, bo nie są one statystycznie istotne!), empirycznych danych na temat skuteczności, lub jej braku, różnych metodyk realizowania projektów IT, w tym i Scruma".

Te linki to:
Dzięki!

wtorek, 29 lipca 2014

Pop-psychologia - artykuł do Quale

Uf, jedna sprawa załatwiona: dostarczyłem (przed terminem!) zamówiony przez Quale artykuł na temat pop-psychologii w IT.

Tam go przetyczacie :-), a poniżej trochę zachęty:

Pop-psychologia w IT

Oni chcieli dostać gotowe rozwiązania
  • Główny problem uczestnika: jak sobie poradzić z programistą w zespole scrumowym, który notorycznie nie wypełnia swoich zobowiązań, bowiem zamiast tego wykonuje różne wrzutki, zlecane mu telefonicznie przez samego prezesa czy mniejszych pod-prezesków.
Gwałtowna potrzeba pop-psychologii
  • Prawdziwość i skuteczność teorii fizycznych jest znacznie łatwiejsza do zweryfikowania, niż teorii psychologicznych. Ktoś, kto zdalną telepatią chciałby wyprzeć telefonię komórkową, szybko wypadłby z obiegu, bo przez telefon da się rozmawiać, a telepatycznie – to nie bardzo. Natomiast kryteria prawdy i nieprawdy w psychologii są mniej jednoznaczne, w najlepszym razie – statystyczne, co wyklucza ich zrozumienie przez 99% ludzi, którzy nie rozumieją, co to jest rozkład normalny, korelacja, związek przyczynowo-skutkowy oraz statystyczna istotność. Myślę, że dotyczy to także 99% informatyków.
Informatycy kochają pop-psychologię
  • Ktokolwiek napisze kod w języku C albo C++ wyrażenie:
          if (a = 17 || b > 36)
  • ... mając nadzieję, że wyrażenie to kiedykolwiek będzie fałszywe, pewnie wyczytawszy na jakimś pop-blogu na temat „operatorów intencjonalnych”, które jakoby zmieniają swą funkcję zgodnie z intencją programisty ;-), szybko przekona się o swojej pomyłce.
Metoda naukowa a modne bzdury
  • Wyobraźmy sobie, że istnieją geny łatwowierności oraz gen myślenia naukowego. Ludzie łatwowierni mają skłonność do postępowania zgodnie z obiegową opinią, słuchania plotek, szybkiego wyrabiania sobie poglądów. W zamian, uzyskują w 40% dostęp do informacji prawdziwej, a w 60% - do fałszywej, ale uzyskują akceptację grupy i dobre samopoczucie.
Co lepsze: sucha teoria czy mokre anegdoty?
  • Śledząc w sieci opinie na temat systemu certyfikacji ISTQB, można często spotkać się z zarzutami, że jest zbyt teoretyczny, że to – cytuję – „sucha teoria”. Wynika z tego, że autor tej krytyki jest zdania, że znajomość teorii nie pomoże mu w praktyce, zaś znajomość przykładów, anegdot – pomoże?
Pop-psychologia i co dalej?
  • Co dalej? Wydorośleć i nie ulegać popularnym głupotom, nie brać za prawdę tego, co tylko hałaśliwe i modne. Opłaca się sceptycznie patrzeć na świat i uważnie badać to, co nam dają do wierzenia.

środa, 23 lipca 2014

NARESZCIE!

Może fejsbukizacja osiągnęła już apogeum, i myślenie zacznie wracać na pozycje, skąd wyparły je modne bzdury?

"Społeczna kontrola prezentowanych treści nie jest jedynym mechanizmem gwarantującym, że są one wiarygodnym źródłem wiedzy. Prezentując standardy zarządzania współpracujemy z organizacjami i instytucjami formalnie nadzorującymi dany standard w naszym kraju. Powołujemy równocześnie Ekspertów Governiki nadając im specjalne uprawnienia w zakresie weryfikacji artykułów, zmiany haseł i kategorii. Do grona tego zapraszamy osoby obdarzone największym zaufaniem, a równocześnie będące uznanymi autorytetami w danej dziedzinie."

(http://www.governica.com/o-projekcie/vademecum)

HUSTEF 2014 w Budapeszcie

HUSTEF 2014

Cieszę się, że jestem w radzie programowej tej naprawdę (wg doświadczeń z ubiegłego roku) fajnej, otwartej i co najważniejsze, inteligentnej, a nie tylko testersko-hakerskiej, konferencji.

Z HUSTEF 2013:


Na temat HUSTEF 2013



Prezentacja "Requirements in Agile Environment"

Ratujmy Kosmos! (tekst z 16 marca 2014)

Udało się po wielkich mozołach doprowadzić do skutku pierwszą w kraju konferencję inżynierii wymagań (wtorek 18 marca, Warszawa, wymagania.computerworld.pl).

Trudy były tak wielkie, bo inżynieria wymagań cierpi na syndrom rozbicia dzielnicowego większy, niż ziemie polskie przed Łokietkiem: realizują ją masowo: programiści (kiedy ktoś im rzuca w pośpiechu bałaganiarskie zadania do realizacji, zwykle na wczoraj), architekci, kierownicy projektów (w końcu trudno zarządzać projektem, nie wiedząc, jaki jest jego cel i z czego będą nas rozliczać), a nawet... testerzy, którzy, choć bez wymagań powinni właściwie spakować się i wyjechać na długi urlop, pracowicie - zgodnie z regułami choroby współuzależnienia i brania na siebie odpowiedzialności za chroniczną nieodpowiedzialność innych - usiłują wymagania pozbierać, uzupełnić, czy wręcz domyśleć się ich (testowanie eksploracyjne).

Tam, gdzie inżynierię wymagań się uprawia, często ukrywa się ją za tajemniczo brzmiącymi nazwami "analizy biznesowej" lub "analizy systemowej". OK, rozumiem, ja wszystko verstehen, ponieważ analiza biznesowa - choć to czubek góry lodowej inżynierii wymagań - wymaga znajomości biznesu, więc "analityk", uprawiając swoją sztukę, postrzegany jest, lub choćby sam siebie postrzega, jako bliski wyższym sferom, gdzie siedzą CEO, CIO, CFO... ale na tym cierpi prawdziwa, całościowa inżynieria wymagań. Można ze schizofrenią i rozdwojeniem jaźni jakoś żyć, ale bywa ciężko :(

Uprawianie dobrej inżynierii wymagań wchodzi w jeszcze jeden sposób tylnymi drzwiami - jako praktyki agile. Wbrew wciąż rozpowszechnionym i zupełnie fałszywym mitom, to właśnie agile usiłuje narzucić projektom jakże potrzebną dyscyplinę, w tym - realizowanie zasad inżynierii wymagań. Cóż, kiedy agile czyni to - żeby podkreślić swoją rzekomą nadzwyczajność? - przy pomocy tak maskującej i zwariowanej terminologii, że słuchając o tych wszystkich sprintach, scrumach, backlogach, pokerach planistycznych i burndownach sam diabeł się nie domyśla, że to o inżynierię wymagań chodzi!

Skutek: o inżynierii wymagań mówi się trochę i podczas wydarzeń poświęconych prawu w IT (zwłaszcza prawu zamówień publicznych - toż to czysta inżynieria wymagań, a SIWZ - to po prostu SRS!), i zarządzaniu projektami, i groźnie brzmiącym sztukom TDD, BDD, ATDD, ale nigdy - spójnie, jako o jednolitym, choć interdyscyplinarnym obszarze wiedzy - INŻYNIERII WYMAGAŃ.

Skoro poważnie brzmiąca inżynieria wymagań troszkę niektórych zdaje się nudzić, to 21 listopada 2014 urządzimy pierwszy w naszej części galaktyki TURNIEJ INŻYNIERII WYMAGAŃ: zawody, krzyk widowni, te rzeczy... (RE-challenge, re-challenge.pl).

Dla zdeterminowanych, zakładamy ORGANIZACJĘ INŻYNIERII WYMAGAŃ: wymagania.org.pl. Zebranie założycielskie już za 4 dni, 19 marca w Warszawie, zapraszamy!

Ciemność widzę, ciemność!

Psychologia, to nauka jak każda inna: bada, buduje teorie, dokonuje obserwacje, przeprowadza eksperymenty. Jednak dla wielu ludzi, tak zwana psychologia stała się swoistą, nowomodną formą religii, mającą za zadanie zbawiać, ratować i uszczęśliwiać. Tak rozumiana, psychologia nie jest już oczywiście nauką, a staje się rzemiosłem i sztuką. Czasem – niestety zbyt często – SZTUKĄ ZAAWANSOWANEGO WCISKANIA KITU. O licznych kłamstwach szarlatanerii, ukrywającej się pod płaszczykiem psychologii, pisze na swoim blogu „W obronie rozumu” Tomasz Witkowski (www.tomaszwitkowski.pl). Uwaga na delfino-terapię i inne szalbierstwa!

Szczególnie podatni na wciskanie im pseudo-psychologii są ludzie nieszczęśliwi, zdesperowani, oraz… informatycy, którzy często traktują każde quasi-psychologiczne modne bzdury z czołobitnym niemal szacunkiem. Skutki tego są dwa, oba niedobre. Dominuje naiwna pseudo-psychologia typu: „cechy idealnego inżyniera wymagań”, albo „jak scrum master powinien rozwiązywać konflikty w zespole scrumowym”, albo rozmaite popularne, lekko faszyzujące teorie przywództwa. Tego serwują nam pod dostatkiem między innymi modne systemy certyfikacji zawodowej IT.

Skutek drugi, to radosna działalność różnych szkółek psychologicznych. Kiedyś, rozmawiając z Akademią… (nomen omen: „profesjonalista w zgodzie ze sobą”), zostałem zapytany, co to takiego „ten agile”, bo właśnie załapali się na prowadzenia warsztatów współpracy w grupie dla zespołów agile pewnej… no, dość znanej firmy informatycznej. Nie są samotni, więc delfino-trapie bezkarnie szerzą się w świecie IT. Szkoda czasu i atłasu, choć zabawa podobno znakomita!

Można by na to machnąć ręką, gdyby nie to, że i psychologia, i socjologia, i antropologia nawet rzeczywiście MAJĄ na realia IT olbrzymi wpływ. Wielu typowych kłopotów projektowych można by unikać, lub chociaż znakomicie łagodzić ich złe skutki, znając ich psychologiczne i społeczne mechanizmy. Inżynieria wymagań, programowanie, testowanie, wdrożenia, zmagają się z trudnościami, z którymi nie poradzi sobie ani najnowsza bajeczka pod znakiem NLP czy innego tao, ani też żaden Ruby, Python, ATDD czy zgoła Cucumber. Natomiast pomaga, stosowana roztropnie - jakie to niemodne dziś słowo! - znajomość dobrze potwierdzonych naukowo zasad psychologii, wsparta umiejętnością zastosowania ich w praktyce, czyli dogłębną znajomością IT oraz inżynierii oprogramowania.

Psychologia projektów IT

Odbyła się pierwsza edycja warsztatów "Psychologia projektów IT", zorganizowanych przez Computerworld.

Kilka spostrzeżeń:

  • Nadal pokutuje mniemanie, że programiści, to odmienna, szczególna grupa o nietypowym profilu psychologicznym, wymagająca jakiegoś niezwykłego podejścia od menedżera. Oczywiście, tak nie jest... ale w warsztatach trzeba będzie brać to przekonanie pod uwagę i tłumaczyć, jak sobie radzić z programistami... choć w rzeczywistości robi się to nie inaczej, niż ze stolarzami :)
  • Uczestnicy widzą możliwości psychologii głównie przez pryzmat rozmaitych scenek i historyjek, które chce się oglądać i przedyskutować, co w tej sytuacji należy zrobić, jak się zachować. Znaczenie psychologicznych mechanizmów w procesie pozyskiwania i analizy wymagań, przy podejmowaniu decyzji, przy zarządzaniu ryzykiem oraz przy projektowaniu interakcji systemu z użytkownikami, jest niezrozumiałe i niedoceniane. Wiele wysiłku wymaga od prowadzącego warsztaty przekonanie uczestników, że psychologia w IT to nie tylko interpersonalne sztuczki i zabawne scenki!
  • Ogromna jest siła przekonania, że psychologia dysponuje potężnymi i skutecznymi narzędziami, pozwalającymi manipulować (oczywiście, w dobrym celu!) ludźmi. Tłumaczenie, że tak nie jest, że psychologia naukowa bardziej opisuje mechanizmy, niż podaje recepty, jak szybko skłonić ludzi do innych niż dotąd zachowań, spotyka się z niedowierzaniem albo budzi niezadowolenie.Mocny przykład, tłumaczący popularność szalbierczych metod, na przykład NLP.
Też wierzycie w NLP i inne modne bzdury? Polecam blog Tomasza Witkowskiego.

Inżynieria wymagań jako III rozbiór Polski

W "Computerworld" artykuł "Zarządzanie projektami: jak definiować oczekiwane rezultaty i nimi zarządzać?". Artykuł traktuje o inżynierii wymagań, cały czas skutecznie omijając właściwe nazwy i udając, że dotyczy zarządzania projektami.

"Wczesne zaangażowanie" opowiada, że projekt trzeba rozpocząć od określenia wymagań, bez tego nici - ale są tam jakby rozważania na temat sprzedaży (?): ani słowa o ani o wizji biznesowej, ani o wymaganiach.

"Zaangażowanie wszystkich stron, zwłaszcza IT" mówi na temat kluczowego procesu określenia granic i kontekstu systemu, o konieczności uwzględnienia wszystkich interesariuszy... nie wymieniając tych nazw, za to cytując jakiegoś Richarda Bextona z Namu Trabel Group. Kto to jest? Co on wie o inżynierii wymagań? Po co go cytować?

"Czytelne i wspólnie uzgodnione priorytety" - owszem, istotne. Priorytety wymagań. Nawet na ten temat jest certyfikat, i szkolenie: IREB CPRE "Pozyskiwanie i konsolidacja wymagań". Nawet będzie wkrótce oferowane jako warsztaty "Computerworld", ale o tym ani słychu, ani widu - artykuł za to udaje, że odkrywa Amerykę, albo zgoła Księżyc, głosząc swoje banały.

Dalej różne zupełne banały na temat zarządzania projektami. Dla kogo to? Piszący w tym piśmie są za dobrzy, żeby nie wiedzieć, że piszą słodkie srutu-tutu... Widać Czytelnicy tego potrzebują?

Traci, jak zwykle, solidna wiedza. Inżynieria wymagań, kluczowa dziedzina, zatraca się rozszarpywana, rozbierana na kawałki: tu kęs wyrwie programowanie, tu zarządzanie projektami, tu - srutu-tutu... a o inżynierii wymagań słuch ginie. I projekty nadal są realizowane tak, jak są, czyli zwykle źle.

Testowanie systemów krytycznych dla bezpieczeństwa - przykład

Testowanie systemów krytycznych dla bezpieczeństwa

W gazeta.pl napisano:
"[...] alarm dźwiękowy w sprzęcie był wyłączony. We wtorek sędzia Agnieszka Witczak - Słoczyńska dociekała, czy była to powszechna praktyka.
- Często zdarzało się, że monitory były głośne, na co skarżyli się inni pacjenci - zeznał 49-letni Piotr W., pracujący w szpitalu chirurg, ale nie na oddziale komercyjnym, na którym odbył się zabieg, w dniu operacji również na urlopie. - Granica była ustawiona zbyt wysoko, co powodowało, że aparatura wyła bardzo często, czyli przy każdym, choćby minimalnym spadku poniżej 80 uderzeń na minutę serca. A powinna być ustawiona tak, by alarmować przy zagrożeniu życia. Częste alarmy mogły wpływać na uśpienie czujności personelu, a że zmian w ustawieniach mógł dokonać tylko serwisant, radzono sobie ją wyłączając."

Tak, testowanie - oraz wymagania wobec - systemów krytycznych dla bezpieczeństwa wymagają wzięcia pod uwagę czynników psychologicznych, do czego ani tak zwani "testerzy", ani "analitycy" nie mają zwykle żadnych kompetencji.

Brawo Santorski!

W najnowszym numerze czasopisma ITWIZ  niezrównany jak zwykle Jacek Santorski pisze: "W Polsce – ale i w innych obszarach postautorytarnych, np. Chinach – nie była potrzebna dotąd innowacyjność. A w związku z tym także partycypacyjność, uruchomienie talentów i relacji ludzi z różnych obszarów organizacji. Przywództwo mogło więc być intuicyjnie folwarczne, czyli takie, jakie poznało się przez nasze poprzednie dekady w organizacjach socjalistycznych, a wcześniej jeszcze, które było specyfiką naszego bardzo uroczego folwarku, w odróżnieniu od manufaktur czy nowoczesnego przemysłu na Zachodzie. Dziś to musi się zmienić."

wtorek, 22 lipca 2014

Thank you, Governica!

http://www.governica.com/
Szanowny Panie Bogdanie,

Pozwoliłem sobie przyznać Panu status Eksperta Governiki, który uprawnia do akceptowania publikowanych artykułów w kategorii Inżynieria Oprogramowania.
W razie pytań jestem do dyspozycji.

Pozdrawiam,
Krzysztof Tomkiewicz

Uzupełniam opisy szkoleń na victo.eu

Uzupełniam opisy kursów, na które wskazuje http://victo.eu/uczenie.html; strasznie to nudne zajęcia, chociaż wszystkie opisy gdzieś mam tam powkładane i gotowe. To samo robię po szwedzku, równie nudne zajęcie.

poniedziałek, 21 lipca 2014

Znów mi sie przelewa: ROZCIEŃCZANIE INŻYNIERII WYMAGAŃ

Jak już pisałem i na tym blogu, i w "Computerwold", w artykule "Inżynieria wymagań wychodzi z ukrycia", inżynierię wymagań uprawiąją wszyscy, ale jakoś cichaczem, milczkiem, pod płaszczykiem innych zajęć. Już nie znajduję, gdzie i kiedy mi się przelało i ulało, i coś o tym napiałem, kiedy przeczytałem - oczywiście pod mylącym nagłówkiem "zarządzania projektami" - o tym, jak ważne dla projektów jest precyzyjne określenie CELU BIZNESOWEGO. Autor nie zająknął się oczywiście nawet o tym, że owszem, jest cała dziedzina wiedzy tym się zajmująca, i że nazywa się... inżynierią wymagań.

Będąc w Krakowie dwa miesiące temu, posłuchałem sobie świeże plotki z jakiegoś kongresu Java, czy innego zjazdu hydraulików/stolarzy (jasne, ponad 1000 uczestników), który się tam jednocześnie odbywał. Najbardziej wygadani hydraulicy (czytaj: specjaliści Java) wygłaszali ponoć (wierzę!) płomienne mowy o tym, jak to programowanie w języku Java / układanie rurek wymaga, aby jasno określić, po co się programuje / dokąd się te rurki ciągnie, a sala ponoć płakała z zachwytu nad odkrywczością tego spostrzeżenia. Dziękujemy, koledzy! Tylko po co tak dyskretnie, anonimowo: nazywajmy rzeczy po imieniu! Mówiliście, że Wasze hydrauliczne umiejętności do niczego nie są przydatne bez... yes, inżynierii wymagań!

Teraz, ledwo włączyłem zaspany jeszcze komp, znowu. Zaproszenie nie spotkanie (po polsku: meeting) workflołowców (workflołarzy?). Nie powinienem sobie tutaj j... żartów z nazwy robić, bo to dziedzina istotna i (w przeciwieństwie do Javizmu) kluczowa dla powodzenia biznesu. Na spotkanie zapraszają "managerów, analityków procesów biznesowych, szefów projektów i team leaderów". Aha... to znaczy, chodzi o inżynierów wymagań ze specjalizacją analiza biznesowa oraz różnych szefów, tąże inżynierią wymagań po cichu się parających (ciekawe, kto w tym czasie kieruje ich projektami i zespołami?). A nie zapominajcie tam, że mówicie o ważnym kawałku bardzo ważnej, interdyscyplinbarnej dziedzinie, zwanej inżynierią wymagań :-)

Właściwie powiniem jeszcze zająć się "architekturą korporacyjną", tym szczególnie wyrafinowanym obszarem zawiłego technicznie wciskania inżynierii wymagań oraz analizy biznesowej wprost w szczegóły implementacji, z pominięciem analizy: "Wróćmy teraz do obszarów skojarzonych z EAM, tj. SOA iBPM, pokazując przykład metodologii J2EZ, czyli Easy SOA w oparciu o platformę J2EE (Java Enterprise). Jak nazwa wskazuje, jest to podejście, które obiecuje szybką implementację, także firmom, które dotąd przykładały mniejszą wagę do systemowego rozwoju IT." Po prostu, bez Jawy ani rusz, możnaby sądzić! Notabene, autor tego artykułu trafnie porównuje architekturę korporacyjną do urbanistyki: dziedziny, dzięki której powstają takie potworki nie do życia jak paryska dzielnica "La Défense" czy miasto (miasto?) Brasília.

Dzień dobry.

niedziela, 20 lipca 2014

Pracowita jesień nadchodzi

Hej, Przyjaciele, nadchodzi (spokojnie, jeszcze mamy sporo czasu) pracowita jesień. Co będę - między innymi - robić, piszę poniżej.
  • Do 1 sierpnia mam termin ostateczny dostarczenia do Quale artykułu na temat "pop-psychologii", NLP i innych modnych bzdur w psychologii zarządzania oraz w IT.
  • Do 20 sierpnia  trzeba złożyć artykuł do "Magazyn RE" (kwartalnik Stowarzyszenia Inżynierii Wymagań) - mój tytuł to "MDRE – długo wyczekiwany mariaż inżynierii wymagań i marketingu".
  • Jak długo zostanę w Karlskrona, jeszcze nie zdecydowałem. 25 uruchamiamy też CFP i oficjalną stronę Turnieju Inżynierii Wymagań, który robimy 4-5 marca 2015 w Warszawie.
  • Agile Management fundacji Governica -  18-19 września. Opowiem o "Psychologii komunikacji w pracy z wymaganiami agile".
  • Agile w Biznesie - "Computerworld", 23-24 września. 24 poprowadzę warsztat "Oszacowanie kosztów i korzysći modeli zwinnych".
  • 25 września - Konferencja SASO w Poznaniu. O, tutaj jest aktualna ulotka konferencji. Opowiem "jakość wymagań a wymagania jakości", czy tak jakoś(ć).
  • 29 września rano - znowu na prom do Karlskrona! Testwarez, 29-30 września. Mam tam prezentację pt. "Testowanie systemów krytycznych dla bezpieczeństwa, wbudowanych i czasu rzeczywistego".
  • I potem jeszcze bardzo szybko do Rzeszowa: podczas "Kongresu Profesjonalistów IT", drugiego października, razem z Ewą Brzeską (Ebitech sp. z o. o.) zadamy głośno pytanie: "Inżyniera wymagań - modna nowinka, fanaberia dostawcy, czy żywotny interes klienta?"



czwartek, 17 lipca 2014

Opowiem na Testwarez o testach systemów krytycznych



Testowanie systemów krytycznych dla bezpieczeństwa, wbudowanych i czasu rzeczywistego: uzasadnienie wyboru tematu


Systemy wbudowane (albo: systemy kontrolne) = embedded systems (control systems), systemy krytyczne dla bezpieczeństwa = safety-critical systems, systemy czasu rzeczywistego (albo: systemy nadążne) = real-time systems. Systemy krytyczne dla bezpieczeństwa są z reguły systemami wbudowanymi, wiele z nich jest także systemami czasu rzeczywistego.

Nie rzucają się w oczy tak, jak obecne wszędzie laptopy, tablety i smartfony, ale naprawdę jest ich znacznie od nich więcej: systemów wbudowanych, sterujących dziesiątkami miliardów urządzeń: pralek automatycznych, pomp paliwowych, samochodów, wind, instrumentów medycznych, robotów przemysłowych, statków i samolotów.

Nie pisze się o nich tak wielu socjologicznych dysertacji jak o Facebook ’u, Twitterze i Google, ale zmieniają one świat, w którym żyjemy, o wiele bardziej: systemy krytyczne dla bezpieczeństwa, którym codziennie – nie myśląc o tym – powierzamy i zawdzięczamy nasze życie i zdrowie.

Nie generują takiej masy tajemniczo brzmiącej terminologii jak wielkie zbiory danych (big data), ale to one właśnie tworzą większość tej oszałamiającej masy danych: systemy czasu rzeczywistego, pozwalające elektronice i oprogramowaniu reagować na zmiany środowiska niemal tak zwinnie i szybko, jak organizmy żywe, dzięki czemu świat zaludniają już dziś miliardy robotów, wykonujących zamiast ludzi prace szczególnie uciążliwe, trudne i niebezpieczne.

Firmom, tworzące produkty zawierające takie właśnie systemy - choć nie jest o nich tak głośno jak o informatycznych molochach, tworzących nieporadne systemy IT, które nam wszystkim utrudniają życie – tym firmom właśnie zawdzięczamy w ogromnym stopniu sukcesy polskiej gospodarki, eksportującej coraz skuteczniej wysoką technologię światowej klasy.

Awarie systemów krytycznych dla bezpieczeństwa są szczególnie tragiczne i bolesne, takie jak na przykład katastrofa w Smoleńsku. Przyczyną tej i wielu podobnych awarii nie była jednak zawodność technologiczna, lecz nieumiejętność uwzględnienia w ich projektowaniu czynników psychologicznych, przez co wzrasta ryzyko niepoprawnych działań ich operatorów, zwłaszcza w stresie.  


Opis
Testowanie systemów krytycznych da bezpieczeństwa spełnia dwa podstawowe zadania: jest dowodem na to, że gotowy system rzeczywiście ma określoną wymaganiami funkcjonalność, niezawodność oraz inne, znaczące dla bezpieczeństwa atrybuty jakości, oraz służy wykrywaniu defektów systemu, dzięki czemu możliwe jest ich usunięcie i osiągnięcia wymaganego poziomu jakości.
Nie wszystkie decyzje dotyczące wymaganej staranności testowania oraz jego metod pozostawione są producentom – wiele z nich określają standardy dla produkcji danego rodzaju systemów.

Korzyści
Słuchacze poznają sposoby organizacji procesu testowego, w tym techniki projektowania przypadków testowych, możliwości oraz ograniczenia automatyzacji oraz budowę środowisk testowych dla wbudowanych systemów krytycznych dla bezpieczeństwa.

Grupa docelowa
Osoby, wykonujące lub mające wykonywać testy systemów krytycznych dla bezpieczeństwa, a także osoby odpowiedzialne za ich organizację i nadzorowanie.

Tematyka
·         Definicja, zakres, specyfika dla testowania: systemy krytyczne dla bezpieczeństwa
·         Definicja, zakres, specyfika dla testowania: systemy wbudowane / kontrolne
·         Definicja, zakres, specyfika dla testowania: systemy czasu rzeczywistego
·         Przegląd norm branżowych dotyczących systemów krytycznych dla bezpieczeństwa
·         Co mówią normy na temat zalecanych metod testowania?
·         Środowiska testowe (środowisko wytwarzania, środowisko docelowe, karta testowa, karta docelowa w środowisku testowym, wirtualizacja testów)
·         Narzędzia stosowane w testowaniu: symulatory, emulator architektury, symulator mikroprocesora (instruction set simulator), karta testowa, debugery, debuger sprzętowy, ICE, inne instrumenty pomiarowe i generatory sygnałów
·         Protokół GPIB (IEEE-488) w testowaniu
·         Narzędzia wspomagające testowanie na przykładzie LabView
·         Dostęp do systemu docelowego, śledzenie przebiegu wykonywania programu, pomiary pokrycia, monitorowanie (analiza dynamiczna), testy po uruchomieniu, testy produkcyjne
·         Inwazyjność narzędzi testowych – miarodajność wyników testów dla bezpieczeństwa
·         Przeglądy kodu źródłowego: cele, zakres, metody
·         Analiza statyczna kodu źródłowego: zakres, korzyści, metody, narzędzia
·         Pomiary pokrycia kodu źródłowego w testach jednostkowych – cele i korzyści, wymagania standardów
·         Pomiary pokrycia kodu źródłowego w testach jednostkowych – techniki i narzędzia
·         Automatyczne generowanie testów jednostkowych – cele, metody, narzędzia
·         Automatyczne generowanie testów funkcjonalnych z modeli wymagań
·         Konieczność automatycznego wykonywania testów – ograniczenia wymagane przez standardy
·         Testowanie atrybutów niefunkcjonalnych – niezawodności i odporności na błędy
·         Testowanie aspektów czasu rzeczywistego oraz osiągów i wydajności
·         Testy eksploracyjne systemów krytycznych dla bezpieczeństwa – korzyści, możliwy zakres

WraszawQA - dziękuję za dobry pomysł

http://quale.pl/pl/warsaw-quality-assurance-group-zapraszamy-do-wspolpracy/

Swietna myśl.

Fajna dyskusja :-) i 8 pomysłów o testowaniu


Jak doszliśmy tutaj:

1. 17 i pół testerskich mitów. Świat mitów i legend w testowaniu wynikiem fejsbukizacji wiedzy. Social networking jest złą wyrocznią, chyba że w sprawach mody.

2. Agile Academy w Szwecji to szkoła policealna. W testowaniu potrzeba mniej inżynierów, a więcej techników. Czy testowanie powinno być więc wykładane w szkołach policealnych?

3. Jak projektować testy wg grafów, rachunku logicznego, teorii zbiorów oraz kombinatoryki, czyli pierwszy pełny i prawdziwy podział metod formalnych - z licznymi odniesieniami, jak ma się on do popularnej taksonomii ISTQB.

4. Zanik dobrej wiedzy testerskiej: czego nie wiemy, jakie modne słowa wyparły jakie dobre metody? Kto nie wie, kim był Boris Beizer?

5. Czy w świecie Continuous Integration projektowanie testów na podstawie wymagań jest archaiczne?

6. Ilościowe metody szacowania opłacalności testów.

7. Tak, testerzy są odkurzaczami i co to naprawdę znaczy? Kiedy lepiej porządkować, zamiast nie śmiecić? 

8. Możliwa rewolucja testowania uwzględniającego kontekst (context-driven testing) oraz HTSM

Pierwszy pomysł

Ostatnio dużo występuję tu i tam, i obserwuję:

  • Masową obsesję pseudo-tematami; nazwałbym to zjawisko "fejsbookizacją wiedzy", takie "fitnesse+cucumber+agile+eksploracyjne+android", w stylu "co i jak tam robiłem i jak użyć narzędzia XX". Trzeba żyć, więc i o tym opowiadam ;-)
  • Widzę też silny opór przed naprawdę ważnymi tematami, np. (a) jak szacować opłacalność testów; (b) na ile testy NIE są sensowną alternatywą dla rozsądniejszych metod zapewnienia jakości, a kiedy - rzadziej niż zwykle myślimy - są; (c) jak projektować testy wg grafów, rachunku logicznego oraz kombinatoryki, czyli prawdziwy podział (metod formalnych), zamiast tej bałaganiarskiej sieczki a la ISTQB. Próbuję, ale nikt nie chce tego słuchać - i ma rację, bo ani tym kolegom-testerom nie zaimponuje, ani pracodawcy nie przekona, bo teraz i pracodawcy chcą być "agile" (wyjaśniam - jestem entuzjastą agile, a wrogiem "agile"). A że lepiej by testował - kogo to obchodzi, ani tym się kariery nie zrobi, ani TestingCup nie wygra.
  • Smutne (a może wesołe?), że w kółko można tłuc te same tematy, a jak się ma znane nazwisko, to gadając to samo od 30 lat można to powtarzać i powtarzać (vide keynotsi na Testwarez, banalni aż zęby bolą, i nie jest to pretensja do organizatorów, sam bym ich wziął robiąc konferencję, ciemny lud to kupi ;-)
  • A lud faktycznie jest ciemny - po prostu nikt się niczego tak naprawdę nie uczy, to co odkryto w latach 70-ych albo wyparły metody gorsze, albo trzeba o tym co pokolenie (2-3 lata) każdemu opowiadać od początku. Ostatnio w opowiadałem o MBT (model-based testing), i to była dla słuchaczy taaaka nooowość (ale Cucumber nie był już dla nich nowością). Nie mam pretensji do słuchaczy, skąd mieli się tego nauczyć, skoro serwuje im się modne gadki i modne narzędzia zamiast wiedzy?
  • Jest silne parcie na modne nowinki, np. ostatnio wyczytałem, że w świecie Continuous Integration "inżynieria wymagań jest archaiczna" ;-)
  • Lekceważenie naprawdę cennych nowin: wielbiona jest ideologia eksploracyjna (= gadki-szmatki że "specyfikacje są złe") i ładne nazwy ("rapid testing"), natomiast mało kto rozumie i uwzględnia istotną wartość filozofii context-driven oraz autentycznie genialny wynalazek Jamesa Bacha, jakim jest HTSM.

Kontra
  • Preferowalibyśmy formy pozbawione złośliwości względem innych przekonań, metodyk czy organizacji. Można zaprezentowac temat kontrowersyjny w taki sposób, by nikogo nie urazić a zachęcić do refleksji. Na takim podejściu chcielibyśmy bazować. Czysta merytoryka bez polityki.

Re-kontra!
  • Stylistyka mojej propozycji faktycznie była kabaretowa, co mam nadzieję nikogo nie uraża - przynajmniej nie było takich intencji. Jeśli kogoś mimo braku intencji uraziła, to ubolewam, ale w takim razie byłby to problem psychologiczny, a nie związany z moją żartobliwie-sarkastyczną formułą tych słów. Psychologiczny dlatego, że przekonania/metodyki/organizacje, do których się tak odniosłem, same stosują podejście o wiele ostrzejsze, wręcz agresywne wobec opinii lub nawet faktów niezgodnych z ich światopoglądem.
  • O "fejsbukizacji" jako społecznym wręcz kryminogennym niekiedy fenomenie i jego negatywnych skutkach pisze praca codzienne, jest to zjawisko powszechnie znane i nie jest to formuła złośliwa wobec facebooka, a wyłącznie wobec zjawisk, jakie powoduje. 
  • Fakt, że wymienione przeze mnie przykładowo naprawdę ważne tematy są systematycznie odrzucane albo przez rady programowe, albo przez rynek (ludzie "chcą słuchać" innych rzeczy), to fakt. Że to, co jest ważne, nie jest często tym, czego chcą słuchać, jest do dowiedzenia i chętnie się tego podejmę na spotkaniu / łamach.
  • "Bałaganiarska sieczka a la ISTQB" jest formą  jak na mnie faktycznie dość ostrą, choć bardzo delikatną w porównaniu z poziomem debaty publicznej na te tematy na forach, ale też adekwatną do dwóch bardzo ważnych zjawisk: (1) tego, że prezentowana przez sylabusy ISTQB klasyfikacja technik projektowania testów jest zasadniczo błędna, niepełna i oparta na zupełnie nieumotywowanych założeniach; (2) że brak jest jakichkolwiek możliwości merytorycznej krytyki wobec założeń ISTQB, spowodowany monopolistyczną pozycją tej organizacji, i nieprzejrzystością jej działań oraz wymogami konformizmu. To zasługuje na bardzo mocną krytykę.
  • Odmowa mocnej dyskusji pod pretekstem bycia "urażonym" w sytuacji, gdy rzeczona organizacja i jej agendy prowadzi politykę mocarstwową i niedemokratyczną, przypomina stylistykę - proszę o wybaczenie określenia, którym znów ktoś może się poczuć urażony - debatę zagraniczną Rosji w sprawach wschodniej Ukrainy, czyli odwracanie kota ogonem. Jeśli ktoś (ISTQB) korzysta z uprzywilejowanej pozycji, nie może udawać wrażliwca, którego uraża mocna dyskusja. I uwaga - polityka bywa przedmiotem merytorycznym. Polityka ISTQB jest niemerytoryczna, lecz polityczna, ale działa obiektywnie na jakość wiedzy testerów. 
  • Zjawisko, że ludzie o modnych nazwiskach opowiadają na konferencjach wciąż te same rzeczy, a powodem ich udziału jest wyłącznie ich nazwisko, nie merytoryka, jest powszechnie znane i ma negatywne konsekwencje. W Polsce dochodzi niestety także - po 25 latach normalności - nadal moda na "zagraniczność" (na seminarium IPMA parę m-cy temu prelegent trafnie to opisał słowami "mówiłem to przez 5 lat, nikt nie słuchał, aż przyjechał jakiś Mike i nagle się wszyscy zafascynowali"). 
  • "Ciemny lud" - ostre i gorzkie słowa. Ponieważ uzyskałem niezależność poglądów i przynależności, i podjąłem decyzję, że nie będę dla uzyskania profitów nikomu schlebiał, nie muszę utrzymywać fikcji, że jesteśmy coraz mądrzejsi i dzielni. Mogę te słowa z łatwością uzasadnić setkami przykładów, albo wręcz udowodnić organizując egzamin. Mogę się powołać np. na wystąpienia Lee Copelanda (CzechTest 2013) i Martina Pola (HUSTEF 2013).
  • Określenie, że wobec "CI inżynieria wymagań jest archaiczna" nie jest moje, bo się z nim nie zgadzam, lecz je cytuję je. To kolejny przykład, jakiego to języka (a w tym blogu było to najłagodniejsze określenie, były też dużo gorsze) używają inni publicznie, masowo.
  • "Gadki-szmatki" - jak wyżej. Arogancja i agresywność Jamesa Bacha i Mikaela Boltona są legendarne, widoczne na forach dyskusyjnych, gdzie oni nieustannie obrażają, co ich nie wielbią. Ja mimo to treść części poglądów Bacha bardzo, bardzo sobie cenię.
Ostateczna propozycja

1. 17 i pół testerskich mitów. Świat mitów i legend w testowaniu wynikiem fejsbukizacji wiedzy. Social networking jest złą wyrocznią, chyba że w sprawach mody.

2. Agile Academy w Szwecji to szkoła policealna. W testowaniu potrzeba mniej inżynierów, a więcej techników. Czy testowanie powinno być więc wykładane w szkołach policealnych?

3. Jak projektować testy wg grafów, rachunku logicznego, teorii zbiorów oraz kombinatoryki, czyli pierwszy pełny i prawdziwy podział metod formalnych - z licznymi odniesieniami, jak ma się on do popularnej taksonomii ISTQB.

4. Zanik dobrej wiedzy testerskiej: czego nie wiemy, jakie modne słowa wyparły jakie dobre metody? Kto nie wie, kim był Boris Beizer?

5. Czy w świecie Continuous Integration projektowanie testów na podstawie wymagań jest archaiczne?

6. Ilościowe metody szacowania opłacalności testów.

7. Tak, testerzy są odkurzaczami i co to naprawdę znaczy? Kiedy lepiej porządkować, zamiast nie śmiecić? 

8. Możliwa rewolucja testowania uwzględniającego kontekst (context-driven testing) oraz HTSM

MDRE - Market-Driven Requirements Engineering



MDRE – długo wyczekiwany mariaż inżynierii wymagań i marketingu

Czytając fascynującą książkę o historii firmy „Apple”, wciąż myślałem, że to tak naprawdę jest opowieść o inżynierii wymagań, choć oczywiście ta nazwa w tekście nie pojawia się ani razu. Książka traktuje o meandrach, jakimi firma poruszała się od lat 70-ych do dzisiaj, wypuszczając na rynek produkty będące raz wielkim sukcesem, raz klęską. Autor opowiada, jak wielki Steve usiłował wstrzelić się w potrzeby rynku, jak tworzył zestawy wymagań wobec swoich kolejnych produktów, jak je zmieniał. 

Nie sposób oprzeć się wrażeniu, że wbrew ugruntowanej tradycji, inżynier wymagań, zajęty ich pozyskiwaniem, i marketingowiec badający rynek, i Steve, właściciel „Apple”, robią w istocie to samo. Nawet można w badaniu rynku dostrzec kawałki analizy biznesowej, gdy analizuje się domniemany tryb pracy potencjalnych klientów.

Nie pierwszy raz o tym myślałem: artykuł, który niedawno umieściłem na tym blogu (http://blogomocja.blogspot.com/2014/06/zadwolenie-klientow-2.html), w pierwotnej formie opublikowałem jeszcze w 2007 roku.

Ta narzucająca się prawda, zgodna zresztą z określeniem inżynierii wymagań przez standard IEEE/ISO 29148 jako „dziedziny interdyscyplinarnej”, bardzo opornie toruje sobie drogę do naszych głów. Zgodnie z uświęconą tradycją, inżynier wymagań gardzi marketingowcem, marketingowiec inżynierem (jak w komiksach „Dilbert”), a tak zwany analityk biznesowy naśmiewa się z obydwu. Inżynier wymagań, wedle folkloru branżowego, chodzi – niczym programista – w dżinsach i niezbyt czystym T-shircie, analityk, w garniturze z krawatem lub bez, ociera się o najwyższe kręgi biznesu i nawet kupując mleko myśli w BPMN-ie, zaś marketingowiec, w stroju hipsterskim, projektuje kosztowne i kłamliwe kampanie reklamowe.

Jeśli tak nawet bywa, to na pewno tak być nie powinno, skoro chcemy działać skutecznie. Tak głosiłem, ale prozelitów wielu nie uzyskałem. Odsiecz przyszła mi z nieoczekiwanego kierunku, bo ze świata akademickiego. Tam, od kilku lat, badania w zakresie inżynierii wymagań objęły nową dziedzinę, nazwaną MDRA – Market-Driven Requirements Engineering. Czyli metody, techniki i procedury, służące do pozyskania i opisania wymagań dla produktów, których użytkownikiem jest odbiorca masowy.

Czym jest MDRE, jak jego zasady wykorzystać w praktyce, jaka jest przyszłość tego wciąż egzotycznego, a bardzo przyszłościowego obszaru wiedzy – o tym napiszę w artykule.