Do meny Certyfikacje inżynierii oprogramowania: po prostu zysk - WARSZTATY

Motto: "Znajomość zasad inżynierii opłaca się bardziej, niż umiejętność posługiwania się młotkiem"

WARSZTATY IREB - SPONSORA KONFERENCJI KKIO
19 września 2013
15:45 - 19:00
(sala 021b)

IREB
                                    logo

*** POPULARNE PRZESĄDY ***
PROGRAM SZCZEGÓŁOWY *** WARUNKI BRZEGOWE ***

<<Prowadzący: Bogdan Bereza, uczestnik wspierający IREB>>

Udział w warsztatach jest bezpłatny, ale prosimy mimo tego o ZGŁOSZENIE: rezerwacja AT victo.eu, aby lepiej orientować się w przewidywanej liczbie uczestników

Uczestnicy warsztatów otrzymują materiały w formie papierowej (czarno-białe) i elektronicznej (PDF), oraz certyfikat udziału w warsztatach, podpisany przez prowadzącego oraz przez przedstawiciela KKIO


POPULARNE PRZESĄDY
Z jednej strony, systemy certyfikacji zdobywają coraz większą liczbę uczestników: PRINCE2® oraz PMI (zarządzanie projektami) mają w tej chwili około 350.000 certyfikowanych uczestników każdy, ISTQB (testowanie) ponad ćwierć miliona. W porównaniu z tymi gigantami, popularność certyfikatów inżynierii wymagań jest na razie niewielka: IREB, choć największy na świecie, wystawił dotąd ponad 12.500 certyfikatów, ale liczba ta w ciągu kilku lat wzrośnie wielokrotnie.

Z drugiej strony, wielu uważa 
certyfikaty inżynierii oprogramowania za zbędną stratę czasu, o ile nie dotyczą konkretnych narzędzi oraz technologii, użytecznych - wydaje się - od zaraz. Pracodawcy i pracownicy, producenci i odbiorcy oprogramowania, jednakowo ulegają temu kosztownemu złudzeniu: znajomość narzędzia to jakoby "konkret", podczas gdy ogólniejsze zasady inżynierii oprogramowania to, jakoby, "sucha teoria", nieprzydatna w praktyce. Jest, oczywiście, DOKŁADNIE ODWROTNIE, ale jak o tym przekonać tych, którzy podejmują decyzje w tych sprawach?

Podczas warsztatów podejmujemy się nietypowego zadania: pokazania czarno na białym, na konkretnych, mierzonych w PLN przykładach, w jaki sposób całkowity koszt udziału w szkoleniu przygotowującym do egzaminu IREB CPRE Foundation (cena szkolenia plus cena egzaminu, plus koszt 3-dniowej nieobecności pracownika) przekłada się na niemal natychmiastowe zyski biznesowe, już po tygodniu po powrocie pracownika ze szkolenia.
Dla porównania, równolegle analizujemy prawdziwość rozpowszechnionego mniemania o korzyściach wynikających ze szczegółowej znajomości wybranych narzędzi lub metodyk, które jednak  są najzupełniej bezużyteczne bez umiejętności ich zastosowania w kontekście, określonym przez inżynierię wymagań.

Oczywiście, dowodzenie przeprowadzamy na przykładzie naszej certyfikacji, IREB CPRE, ale działamy w interesie wszystkich, bo podobne argumenty dotyczą wielu innych - przynajmniej tych uczciwych - systemów certyfikacji.

PROGRAM SZCZEGÓŁOWY

Finansowa korzyść uzyskana dzięki wiedzy zdobytej podczas szkolenia przygotowującego do certyfikacji IREB (na przykładzie kolejnych 9 rozdziałów sylabusa IREB CPRE)
Dla porównania: czy można z tego korzystać bez znajomości zasad inżynierii wymagań?
"Programowanie w świecie nowych technologii"
blue
1. WPROWADZENIE I PODSTAWY INŻYNIERII WYMAGAŃ
Wbrew temu, czego można oczekiwać, wielu uczestników oraz innych interesariuszy projektów informatycznych tylko niejasno zdaje sobie sprawę, czym są wymagania, czym różni się dokumentacja wymagań od dokumentacji technicznej, a obie - czym różnią się od specyfikacji projektu. Awarie systemów i niepowodzenia w projektach przypisuje się wszelkim możliwym przyczynom, ale rzadko przyczynie najpowszechniejszej - niedostatkom wymagań.
Przykład biznesowy: odróżnienie specyfikacji projektu, specyfikacji wymagań oraz specyfikacji technicznej oprogramowania i jakie z tego wynikły korzyści.
"Selenium"

Jeden z setek programów do automatyzacji wykonywania testów, głównie tzw. metodą "zarejestruj-odtwórz". Możliwość tworzenia testów, które następnie będą wykonywane automatycznie, zależy od dobrej znajomości i względnej stabilności wymagań; w przeciwnym razie staje się de facto pozyskiwaniem wymagań.

green
2. SYSTEM I KONTEKST SYSTEMU
Wiele spektakularnych katastrof okazuje się, po zanalizowaniu, spowodowanych nieporozumieniami dotyczącymi tego, co właściwie wchodzi w skład systemu. To zaskakujące, jak bardzo nisko-technologiczne są przyczyny awarii wysoko-technologicznych systemów: nieporozumienia w komunikacji między ludźmi.
Przykład biznesowy: dotyczący systemu przepis prawa, wykryty dzięki znajomości pojęcia KONTEKST SYSTEMU, i jakich dzięki temu uniknięto kosztów.
"Ruby on Rails"

Jeden z dziesiątków frameworków organizujących i ułatwiających tworzenie aplikacji webowych. Często przytaczany na jego rzecz argument argument to "szybkość, łatwość i przyjemność pisania kodu". OK, ale co ten kod ma robić? - to określają wcześniej znalezione i opisane wymagania.
blue
3. POZYSKIWANIE WYMAGAŃ
Prowadzone przez informatyków wykłady na temat pozyskiwania wymagań niekiedy robią nieco komiczne wrażenie: zaaferowany wykładowca próbuje opowiadać o aktywnym słuchaniu, mowie ciała itp psychologicznych zjawiskach. W rzeczywistości nie chodzi o psychologiczne subtelności, niemniej sprawna organizacja procesu pozyskiwania (definiowania, znajdowania, poszukiwania, określania) wymagań jest BEZWZGLĘDNIE KLUCZOWA dla projektu, choć ma taki na pozór nieinżynierski charakter.
Przykład biznesowy: wymagania, których pominięcie kosztowało by wieleset tysięcy, znalezione dzięki metodzie tak zwanego terminowania.
Więcej na temat pozyskiwania, walidacji i negocjowania wymagań można się nauczyć na kursie przygotowującym do
egzaminu na certyfikat zaawansowany IREB "Pozyskiwanie i konsolidacja wymagań".
"Capybara" oraz "Cucumber"

Tak, to fajne zabawki... perełki dla rubinu na kółkach. Uwaga: naprawdę to są dobre, błyskotliwe narzędzia. Ich skuteczne wykorzystanie jest możliwe pod warunkiem, że dobrze określiło się to, co ma być zbudowane, i znane są warunki testowe: wyniki pracy inżynierii wymagań.
green
4. DOKUMENTACJA WYMAGAŃ
Nie ma czasu na pisanie dokumentacji, kiedy trzeba jak najszybciej przystąpić do tworzenia działającego kodu? Temat odwiecznego sporu między zwolennikami kodu i zwolennikami dokumentacji jest niewłaściwie postawionym pytaniem: konieczny jest wyłącznie kod, a dokumentacja wymagań, to wyłącznie NIEZBĘDNE rusztowanie.
Przykład biznesowy: kluczowe wymaganie przysłano mailem. Ile kosztowałyby wynikające z tego nieporozumienia, gdyby ich osoba po szkoleniu IREB CPRE w porę nie rozbroiła.
"Fitnesse"

Tylko... skąd wziąć znajomość kryteriów do testów akceptacyjnych, realizowanych przy pomocy tej platformy? Jaką treść wkładać do Fitnesse-wiki? Tak, oczywiście: tę, którą określa inżynieria wymaga n :-)
blue
5. DOKUMENTACJA W JĘZYKU NATURALNYM
Język naturalny jest chronicznie niejednoznaczny - tak nauczamy, uczestnicy szkoleń kiwają głowami, wracają do firmy... i wszystko zostaje po staremu.
Przykład biznesowy: jak zastosowanie wzorców językowych, o których prowadzący nudził na kursie IREB CPRE, pozwoliło kosztem 15 zł / osobę oszczędzić setki tysięcy w dwa tygodnie.
Na podstawie niejednoznacznego opisu w języku naturalnym mamy stworzyć jednoznaczny kod? To będzie trudne, o ile nie umiemy sobie z tym poradzić.
green
6. ZASTOSOWANIE MODELI WYMAGAŃ
Przykład biznesowy: tym razem dokonamy ogólną analizę kosztów i korzyści z zastosowania diagramów aktywności oraz diagramów przejść stanów (UML) - wprawdzie jednych z wielu, ale najpopularniejszych pół-formalnych modeli wymagań.
Podstawowy sylabus IREB CPRE nie uczy ich szczegółowo - tylko przypomina o ich istnieniu. Szczegółowo różnych metod modelowania można się nauczyć na kursie przygotowującym do egzaminu na certyfikat zaawansowany IREB "Modelowanie wymagań".
Certyfikowany "Scrum Master"

Jak piszą guru: "Agile Scrum jest łatwo zrozumieć, nietrudno się go nauczyć, ale bardzo trudno opanować." Tak, zarządzanie zespołem to niełatwa umiejętność, nawet dla certyfikowanego mistrza młyna. Dlatego warto wiedzieć, skąd bierze się "product backlog" (z wymagań) oraz "sprint backlog"(z priorytetów wymagań)
blue
7. NEGOCJOWANIE I WALIDACJA WYMAGAŃ
Znowu psychologia, co gorsza pomieszana z polityką.
Przykład biznesowy: jak - nabyta na szkoleniu - podstawowa wiedza o sposobach i korzyściach negocjowania i walidacji wymagań położyła kres kosztownym, chronicznym nieporozumieniom.
Aplikacje na platformie "Android"

Oraz Blackberry, iOS, Asha, Sailfish OS, Windows Phone, Windows RT, Bada, Blackberry OS... Poznawajmy je w miarę potrzeby, tak jak inne wymagania dla platformy.
green
8. ZARZĄDZANIE ZMIANAMI WYMAGAŃ
Wszyscy deklarują zgodę na prosty fakt, że przestrzeganie prostych, niezbyt bolesnych zasad i procedur zarządzania zmianami kosztuje o wiele mniej, niż drobne zaniedbania, kumulujące się przez dni i tygodnie. Przykład biznesowy: jak uczestnik kursu IREB CPRE, wróciwszy do firmy, uzasadnił potrzebę i wdrożył funkcjonujący system CCM dla wymagań, i jakie korzyści firma odniosła z tego rozwiązania.
Znajomość "HP Quality Centre"

Jeden z setek programów do zarządzania testami i wymaganiami. Bardzo dobry, dość kosztowny. Osoba znająca zasady zarządzania zmianami wymagań opanuje ten program w tydzień; osoba znająca ten program użyje go niewłaściwie, jeśli nie zna się na zarządzaniu zmianami wymagań
blue
9. NARZĘDZIA INŻYNIERII WYMAGAŃ
Oczywiście, śledzenie powiązań wymagań jest pożądane, tylko... nigdy nie ma czasu na jego wdrożenie, a tym bardziej na utrzymanie, prawda?
Przykład biznesowy: co się zdarzyło, kiedy kluczowy pracownik nagle odszedł, by założyć własną firmę? To się zdarza - ale negatywne skutki można ograniczyć, stosując dobre praktyki śledzenia powiązań wymagań przy pomocy narzędzi.
Olśniewająca wirtuozeria w "Phyton"

  Niezły język programowania, tak jak dziesiątki innych, podobnych. Jeśli go stosujemy, trzeba go poznać. Nie zastąpi inżynierii wymagań. Umożliwia realizację celów wskazanych przez inżynierię wymagań.
góra strony

WARUNKI BRZEGOWE

Popularnym mitem, uzasadniającym pozornie rezygnację ze szkoleń i stosowania dobrych metodyk inżynierii oprogramowania, bywa tak zwany "kryzys". Niektórzy wydają się być zdania, że pozwolić sobie na luksus bycia dobrym  można tylko w warunkach jakiejś fikcyjnej prosperity, jak nakręcona bezmyślnie rozluźnionymi warunkami kredytowymi hossa pożyczkowa w latach 2001-2007 w Hiszpanii, albo jak psujące rynek szkoleniowy, zbiurokratyzowane dofinansowania szkoleń z funduszy EFS; zaś kiedy rządzą rynkowe i biznesowe realia, trzeba stawiać na bylejakość?

Jak zwykle z z biznesowym folklorem, jest dokładnie odwrotnie, niż głoszą mity. Piszemy o tym więcej w artykule "Nareszcie kryzys!".

Nie każde szkolenie (warsztat, seminarium, wykład, prezentacja na konferencji) się opłaca, nie z każdego wychodzimy mądrzejsi i sprawniejsi. Kursy nudne, byle jakie, sztampowe, prowadzone przez niedoświadczonych, za to bardzo pewnych siebie instruktorów ze znajomością paru reguł i dwóch narzędzi, są marnowaniem czasu. Więcej na ten temat piszemy w artykułach "Kupując wiedzę - przewodnik po szkoleniach" oraz w "Jak sprzedawać nietypowe szkolenia? Podręcznik cynicznego sprzedawcy"
.

Osoby, decydujące o udziale pracowników korporacji w szkoleniach, lubią swoiście pojmowany konkret. Wysłany pracownik powinien dostać ładnie wydrukowany certyfikat uczestnictwa i gruby plik solidnie  wydrukowanych materiałów, firmową torbę i reklamowy długopis. Dobre są też certyfikaty - stąd zmora szkoleń pseudo-certyfikowanych, których uczestnicy otrzymują, po zdaniu jakiegoś egzaminu, "międzynarodowy" certyfikat, firmowany przez... samą firmę szkoleniową. Jak odróżnić dobre, solidne systemy certyfikacji od podróbek? Pisaliśmy o tym w artykule "Open Accreditation for Better Certification" (w "Professional Tester", październik 2011), oraz na portalu cosic.testerzy.org.pl.
góra strony
© Victo 2013
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
---