Dziękujemy za wysłanie zapytania! Jeden z członków naszego zespołu skontaktuje się z Państwem wkrótce.
Dziękujemy za wysłanie rezerwacji! Jeden z członków naszego zespołu skontaktuje się z Państwem wkrótce.
Plan Szkolenia
Inżynieria oprogramowania - 5 dni
Dzień 1: Zarządzanie projektami
- Zarządzanie projektem a zarządzanie liniowe oraz utrzymanie i wsparcie
- Definicja projektu i formy projektów
- Zarządzanie – ogólne zasady i zarządzanie projektami
- Style zarządzania
- Co jest szczególne w projektach IT?
- Podstawowy proces projektowy
- Iteracyjny, przyrostowy, kaskadowy, zwinny i szczupły proces projektowy
- Fazy projektu
- Role w projekcie
- Dokumentacja projektu i inne artefakty
- Czynniki miękkie i zarządzanie ludźmi
- PRINCE 2, PMBOK, PMI, IPMA i inne standardy projektowe
Dzień 2: Podstawy analizy biznesowej i inżynierii wymagań
- Definiowanie celów biznesowych
- Analiza biznesowa, zarządzanie procesami biznesowymi, doskonalenie procesów biznesowych
- Granica między analizą biznesową a analizą systemową
- Interesariusze systemu, użytkownicy systemu, kontekst systemu i granice systemu
- Dlaczego wymagania są konieczne?
- Czym jest inżynieria wymagań
- Granica między inżynierią wymagań a projektowaniem architektonicznym
- Gdzie często ukrywa się inżynieria wymagań?
- Inżynieria wymagań w rozwoju iteracyjnym, szczupłym i zwinnym oraz w ciągłej integracji – FDD, DDD, BDD, TDD
- Podstawowy proces inżynierii wymagań, role i artefakty
- Standardy i certyfikacje: BABOK, ISO/IEEE 29148, IREB, BCS, IIBA
Dzień 3: Podstawy architektury i rozwoju
- Języki programowania – paradygmaty strukturalne i obiektowe
- Rozwój obiektowy – ile to historia, a ile przyszłość
- Modularność, przenośność, utrzymywalność i skalowalność architektur
- Definicja i typy architektur oprogramowania
- Architektura przedsiębiorstwa i architektura systemu
- Style programowania
- Środowiska programistyczne
- Błędy programistyczne i jak ich unikać i zapobiegać
- Modelowanie architektury i komponentów
- SOA, Web Services i mikroserwisy
- Automatyczne budowanie i ciągła integracja
- Ile projektowania architektury jest w projekcie?
- Programowanie ekstremalne, TDD i refaktoryzacja
Dzień 4: Podstawy zapewnienia jakości i testowania
- Jakość produktu: co to jest? ISO 25010, FURPS itp.
- Jakość produktu, doświadczenie użytkownika, model Kano, zarządzanie doświadczeniem klienta i integralna jakość
- Projektowanie zorientowane na użytkownika, persony i inne sposoby na indywidualizację jakości
- Wystarczająca jakość
- Zapewnienie jakości i kontrola jakości
- Strategie ryzyka w kontroli jakości
- Składniki zapewnienia jakości: wymagania, kontrola procesu, zarządzanie konfiguracją i zmianami, weryfikacja, walidacja, testowanie, testowanie statyczne i analiza statyczna
- Zapewnienie jakości oparte na ryzyku
- Testowanie oparte na ryzyku
- Rozwój oparty na ryzyku
- Krzywa Boehma w zapewnieniu jakości i w testowaniu
- Cztery szkoły testowania – która odpowiada twoim potrzebom?
Dzień 5: Typy procesów, dojrzałość i doskonalenie procesów
- Ewolucja procesów IT: od Alana Turinga przez Big Blue do lean startup
- Proces i organizacja zorientowana na proces
- Historia procesów w rzemiośle i przemyśle
- Modelowanie procesów: UML, BPMN i więcej
- Zarządzanie procesami, optymalizacja procesów, reengineering procesów i systemy zarządzania procesami
- Innowacyjne podejścia do procesów: Deming, Juran, TPS, Kaizen
- Czy (procesowa) jakość jest darmowa? (Philip Crosby)
- Potrzeba i historia doskonalenia dojrzałości: CMMI, SPICE i inne skale dojrzałości
- Specjalne typy dojrzałości: TMM, TPI (do testowania), Dojrzałość Inżynierii Wymagań (Gorschek)
- Dojrzałość procesu a dojrzałość produktu: czy istnieje korelacja? Czy istnieje związek przyczynowy?
- Dojrzałość procesu a sukces biznesowy: czy istnieje korelacja? Czy istnieje związek przyczynowy?
- Zapomniana lekcja: Automatyczne zapobieganie defektom i kolejny skok w produktywności
- Próby: TQM, SixSigma, retrospektywy agile, ramy procesowe
Inżynieria wymagań - 2 dni
Dzień 1: Pozyskiwanie, negocjowanie, konsolidowanie i zarządzanie wymaganiami
- Wyszukiwanie wymagań: co, kiedy i przez kogo
- Klasyfikacja interesariuszy
- Zapomniani interesariusze
- Definiowanie kontekstu systemu – określanie źródeł wymagań
- Metody i techniki pozyskiwania wymagań
- Prototypowanie, persony i pozyskiwanie wymagań poprzez testowanie (eksploracyjne i inne)
- Marketing i pozyskiwanie wymagań – MDRA („Market-Driven Requirements Engineering”)
- Priorytetyzacja wymagań: MoSCoW, Karl Wiegers i inne techniki (w tym zwinne MMF)
- Doskonalenie wymagań – zwinne „specyfikowanie przez przykłady”
- Negocjowanie wymagań: rodzaje konfliktów, metody rozwiązywania konfliktów
- Rozwiązywanie wewnętrznych niespójności między niektórymi typami wymagań (np. bezpieczeństwo a łatwość użytkowania)
- Śledzenie wymagań – dlaczego i jak
- Zmiany statusu wymagań
- CCM wymagań, wersjonowanie i punkty odniesienia
- Widok produktu i widok projektu na wymagania
- Zarządzanie produktem i zarządzanie wymaganiami w projektach
Dzień 2: Analiza, modelowanie, specyfikacja, weryfikacja i walidacja wymagań
- Analiza to myślenie i ponowne myślenie, które wykonujesz między pozyskiwaniem a specyfikacją
- Proces wymagań jest zawsze iteracyjny, nawet w projektach sekwencyjnych
- Opisywanie wymagań w języku naturalnym: ryzyka i korzyści
- Modelowanie wymagań: korzyści i koszty
- Zasady używania języka naturalnego do specyfikacji wymagań
- Definiowanie i zarządzanie słownikiem wymagań
- UML, BPMN i inne formalne i półformalne notacje do modelowania wymagań
- Używanie szablonów dokumentów i zdań do opisu wymagań
- Weryfikacja wymagań – cele, poziomy i metody
- Walidacja – z prototypowaniem, przeglądami i inspekcjami oraz testowaniem
- Walidacja wymagań a walidacja systemu
Testowanie - 2 dni
Dzień 1: Projektowanie testów, wykonanie testów i testowanie eksploracyjne
- Projektowanie testów: po testowaniu opartym na ryzyku, wybór optymalnego sposobu wykorzystania dostępnego czasu i zasobów
- Projektowanie testów „od nieskończoności do tutaj” – wyczerpujące testowanie nie jest możliwe
- Przypadki testowe i scenariusze testowe
- Projektowanie testów na różnych poziomach testowych (od poziomu jednostkowego do poziomu systemowego)
- Projektowanie testów do testowania statycznego i dynamicznego
- Projektowanie testów zorientowane na biznes i na technikę („czarna skrzynka” i „biała skrzynka”)
- Próby zepsucia systemu („testowanie negatywne”) i wsparcie dla deweloperów (testowanie akceptacyjne)
- Projektowanie testów do osiągnięcia pokrycia testowego – różne miary pokrycia testowego
- Projektowanie testów oparte na doświadczeniu
- Projektowanie przypadków testowych z wymagań i modeli systemowych
- Heurystyki projektowania testów i testowanie eksploracyjne
- Kiedy projektować przypadki testowe? – tradycyjne i eksploracyjne podejście
- Opisywanie przypadków testowych – ile szczegółów?
- Wykonywanie testów – aspekty psychologiczne
- Wykonywanie testów – logowanie i raportowanie
- Projektowanie testów do „niefunkcjonalnego” testowania
- Automatyczne projektowanie testów i MBT (Model-Based Testing)
Dzień 2: Organizacja, zarządzanie i automatyzacja testów
- Poziomy testowania (lub fazy)
- Kto wykonuje testy i kiedy? – różne rozwiązania
- Środowiska testowe: koszt, administracja, dostęp, odpowiedzialność
- Symulatory, emulatory i wirtualne środowisko testowe
- Testowanie w zwinnych scrumach
- Organizacja i rola zespołu testowego
- Proces testowania
- Automatyzacja testów – co można zautomatyzować?
- Automatyzacja wykonywania testów – podejścia i narzędzia
63 godzin
Opinie uczestników (3)
Dobre przygotowanie merytoryczne trenera. Dodatkowo, trener angażował uczestników nawet w części wykładowej, zachęcał do "brainstormingu", dzielenia się swoimi spostrzeżeniami, pomysłami.
Krzysztof Wojciechowski - HUUUGE GAMES SPOLKA Z OGRANICZONA ODPOWIEDZIALNOSCIA
Szkolenie - Test Automation with Selenium and Python
ćwiczenia praktyczne, łatwiej przyswoić informacje
ashley bolen - Insurance Corporation of British Columbia
Szkolenie - Test Automation with Selenium
Przetłumaczone przez sztuczną inteligencję
Podobało mi się, że trener miał praktyczną wiedzę z dziedziny testowania i że pytał o to, jak poszczególne aspekty wyglądają u nas. Dobrze, że trener zaznaczał, że niektóre elementy po prostu tak wyglądają wg ISTQB, gdy czasem prowadziliśmy dyskusję na temat danego rozwiązania zadania, z którym się do końca nie zgadzamy.