Farley David (1959- )
Sortowanie
Źródło opisu
Książki, czasopisma i zbiory specjalne
(2)
Forma i typ
Książki
(2)
Publikacje fachowe
(2)
Publikacje dydaktyczne
(1)
Dostępność
dostępne
(2)
tylko na miejscu
(2)
Placówka
Wypożyczalnia
(2)
Biblioteka WEAiI
(2)
Autor
Berłowski Paweł
(189)
Kotowski Włodzimierz
(179)
Praca zbiorowa
(157)
Skoczylas Zbigniew
(152)
Stiasny Grzegorz
(143)
Farley David (1959- )
(-)
Sadlik Ryszard
(142)
Blum Maciej
(140)
Michalski Dariusz
(134)
Lewandowski Maciej
(131)
Majewski Jerzy S
(131)
Etzold Hans-Rüdiger
(120)
Leśniewski Mariusz
(116)
Gewert Marian
(108)
Maruchin Wojciech
(107)
Guryn Halina
(105)
Traczyk Wojciech
(101)
Chalastra Michał
(99)
Kardyś Marta
(97)
Marx Karl (1818-1883)
(94)
Nazwisko Imię
(94)
Berkieta Mateusz
(93)
Tomczak Małgorzata
(93)
Polkowski Sławomir
(92)
Engels Friedrich (1820-1895)
(91)
Jakubiec Izabela
(90)
Kotapski Roman
(90)
Rybicki Piotr
(90)
Krysicki Włodzimierz (1905-2001)
(88)
Teleguj Kazimierz
(88)
Kapołka Maciej
(86)
Mikołajewska Emilia
(84)
Zaborowska Joanna
(81)
Piątek Grzegorz
(79)
Rudnicki Bogdan
(79)
Starosolski Włodzimierz (1933- )
(79)
Górczyński Robert
(78)
Meryk Radosław
(78)
Polit Ryszard
(77)
Mroczek Wojciech
(76)
Kulawik Marta
(74)
Mycielski Krzysztof
(74)
Myszkorowski Jakub
(73)
Konopka Eduard
(71)
Jabłoński Marek
(70)
Bielecki Jan (1942-2001)
(69)
Knosala Ryszard (1949- )
(68)
Rajca Piotr (1970- )
(68)
Rymarz Małgorzata
(68)
Walczak Krzysztof
(68)
Walkiewicz Łukasz
(68)
Wiecheć Marek
(68)
Jabłoński Adam
(67)
Laszczak Mirosław
(66)
Piwko Łukasz
(66)
Wodziczko Piotr
(65)
Dziedzic Zbigniew
(64)
Sidor-Rządkowska Małgorzata
(64)
Żakowski Wojciech (1929-1993)
(64)
Pasko Marian
(62)
Włodarski Lech (1916-1997)
(62)
Czakon Wojciech
(61)
Leyko Jerzy (1918-1995)
(61)
Jankowski Mariusz
(60)
Kostecka Alicja
(60)
Lenin Włodzimierz (1870-1924)
(60)
Paszkowska Małgorzata
(60)
Wróblewski Piotr
(60)
Karpińska Marta
(59)
Próchnicki Wojciech
(59)
Rogala Elżbieta
(59)
Bielecki Maciej
(57)
Jelonek Jakub
(57)
Malkowski Tomasz
(57)
Pilch Piotr
(57)
Rauziński Robert (1933- )
(57)
Gawrońska Joanna
(56)
Ajdukiewicz Andrzej (1939- )
(55)
Cieślak Piotr
(55)
Draniewicz Bartosz
(55)
Godek Piotr
(55)
Osiński Zbigniew (1926-2001)
(55)
Jasiński Filip
(54)
Kuliński Włodzisław
(54)
Suchodolski Bogdan (1903-1992)
(54)
Forowicz Krystyna
(53)
Klupiński Kamil
(53)
Szkutnik Leon Leszek
(52)
Zdanikowski Paweł
(52)
Wantuch-Matla Dorota
(51)
Barowicz Marek
(50)
Trammer Hubert
(50)
Walczak Tomasz
(50)
Watrak Andrzej
(50)
Zgółkowa Halina (1947- )
(50)
Barańska Katarzyna
(49)
Czajkowska-Matosiuk Katarzyna
(49)
Jurlewicz Teresa
(49)
Pikoń Andrzej
(49)
Szargut Jan (1923- )
(49)
Chojnacki Ireneusz
(48)
Rok wydania
2020 - 2024
(1)
2010 - 2019
(1)
Okres powstania dzieła
2001-
(2)
Kraj wydania
Polska
(2)
Język
polski
(2)
Odbiorca
Menedżerowie
(2)
Programiści
(2)
Inżynierowie
(1)
Temat
Programy komputerowe
(2)
Automatyzacja
(1)
Bazy danych
(1)
Optymalizacja
(1)
Programowanie
(1)
Programowanie (informatyka)
(1)
Projektowanie
(1)
Weryfikacja oprogramowania
(1)
Zarządzanie projektami
(1)
Zwinne zarządzanie
(1)
Gatunek
Podręcznik
(2)
Dziedzina i ujęcie
Informatyka i technologie informacyjne
(2)
Zarządzanie i marketing
(1)
2 wyniki Filtruj
Książka
W koszyku
Na stronie 4. okładki także nazwa wydawcy oryginału: Pearson Addison-Wesley.
Dla programistów, menedżerów, inżynierów i liderów technicznych.
Czym jest inżynieria oprogramowania? Inżynieria - praktyczne zastosowanie nauki Zmiana paradygmatu To nie produkcja jest naszym problemem Inżynieria projektowa zamiast inżynierii produkcyjnej Inżynieria != kod Ograniczenia rzemiosła Precyzja i skalowalność Radzenie sobie ze złożonością Powtarzalność i precyzja pomiarów Inżynieria, kreatywność i rzemiosło Dlaczego to, co robimy, nie jest inżynierią oprogramowania Kompromisy Iluzja postępu Droga od rzemiosła do inżynierii Rzemiosło to za mało. Podstawy podejścia inżynieryjnego Branża zmian? Znaczenie pomiarów Wprowadzanie stabilności i wydajności Podstawy inżynierii oprogramowania Eksperci od uczenia się Eksperci od radzenia sobie ze złożonością Optymalizacja z myślą o uczeniu się . Praca w modelu iteracyjnym Praktyczne zalety podejścia iteracyjnego Podejście iteracyjne jako strategia projektowania defensywnego Pokusa tworzenia planu Praktyczne aspekty podejścia iteracyjnego Informacje zwrotne Praktyczny przykład ilustrujący znaczenie informacji zwrotnych Informacje zwrotne w czasie pisania kodu Informacje zwrotne na etapie integracji Informacje zwrotne na etapie projektowania Informacje zwrotne w architekturze Preferuj szybkie informacje zwrotne Informacje zwrotne w kontekście projektu produktu Informacje zwrotne w organizacji i kulturze Podejście przyrostowe Znaczenie modułowości Podejście przyrostowe w organizacjach Narzędzia ułatwiające przyrostową pracę Ograniczanie zakresu wpływu zmian Projektowanie przyrostowe Podejście empiryczne Zakorzenienie w rzeczywistości Oddzielenie podejścia empirycznego od eksperymentów "Znam ten błąd!" Unikanie oszukiwania samego siebie Wymyślanie rzeczywistości pasującej do argumentów Kierowanie się rzeczywistością Nastawienie na eksperymentowanie Czym jest "nastawienie na eksperymentowanie"? Informacje zwrotne Hipotezy Pomiary Kontrolowanie zmiennych Zautomatyzowane testy jako eksperymenty Zapewnianie kontekstu dla wyników testów przeprowadzanych w ramach eksperymentów Zakres eksperymentów Optymalizowanie z myślą o radzeniu sobie ze złożonością Modułowość Cechy charakterystyczne modułowości Niedocenianie znaczenia dobrego projektu Znaczenie testowalności Projektowanie z myślą o łatwości testowania poprawia modułowość Usługi i modułowość Łatwość wdrażania a modułowość Modułowość w różnych skalach Modułowość w systemach ludzkich Spójność Modułowość i spójność - podstawy projektowania Prosty przykład niskiej spójności Kontekst ma znaczenie Wysoce wydajne oprogramowanie Związki z powiązaniami Zapewnianie wysokiej spójności za pomocą programowania sterowanego testami Jak uzyskać spójne oprogramowanie? Koszty niskiej spójności Spójność w systemach ludzkich Podział zadań Wstrzykiwanie zależności Oddzielanie złożoności zasadniczej od złożoności przypadkowej Znaczenie podejścia DDD Testowalność Porty i adaptery Kiedy stosować wzorzec porty i adaptery? Czym jest API? Stosowanie programowania sterowanego testami do wprowadzania podziału zadań Ukrywanie informacji i abstrakcja Abstrakcja lub ukrywanie informacji Co jest powodem powstawania "wielkiej błotnej bryły"? Problemy organizacyjne i kulturowe Problemy techniczne i problemy projektowe Obawy przed "nadinżynierią" Tworzenie bardziej abstrakcyjnego kodu za pomocą testów Wartość abstrakcji "Dziurawe" abstrakcje Wybór odpowiednich abstrakcji Abstrakcje z dziedziny problemu Wyodrębnianie złożoności przypadkowej za pomocą abstrakcji Izolowanie zewnętrznych systemów i zewnętrznego kodu Zawsze preferuj ukrywanie informacji. Radzenie sobie z powiązaniami Koszty powiązań Skalowanie Mikrousługi Wyeliminowanie powiązań może prowadzić do większej ilości kodu Luźne powiązanie nie jest jedynym, które ma znaczenie Preferuj luźne powiązania W czym powiązania różnią się od podziału zadań? Zasada DRY jest zbyt uproszczona Asynchroniczność jako narzędzie do uzyskiwania luźnych powiązań Projektowanie z myślą o luźnych powiązaniach Luźne powiązania w systemach ludzkich Narzędzia ułatwiające inżynierię w branży oprogramowania Narzędzia w dziedzinie inżynierii Czym jest rozwój oprogramowania? Testowalność jako narzędzie Punkty pomiaru Problemy z osiąganiem testowalności Jak zwiększyć testowalność? Łatwość wdrażania Szybkość Kontrolowanie zmiennych Ciągłe dostarczanie Ogólne narzędzia wspomagające inżynierię Współczesny inżynier oprogramowania Inżynieria jako proces ludzki Organizacje dokonujące przełomu w świecie cyfrowym Skutki a mechanizmy
Sygnatura czytelni BWEAiI: XII J 121
Ta pozycja znajduje się w zbiorach 2 placówek. Rozwiń listę, by zobaczyć szczegóły.
Wypożyczalnia
Są egzemplarze dostępne do wypożyczenia: sygn. 153923 N (1 egz.)
Biblioteka WEAiI
Egzemplarze są dostępne wyłącznie na miejscu w bibliotece: sygn. 153924 N (1 egz.)
Książka
W koszyku
U dołu okładki: Dostarczaj oprogramowanie na zawołanie!
Bibliografia na stronach 427-428. Indeks.
PODSTAWY Problem dostarczania oprogramowania Niektóre powszechnie występujące błędne wzorce wydawania oprogramowania Antywzorzec: ręczne wdrażanie oprogramowania Antywzorzec: wdrożenie w środowisku zbliżonym do środowiska produkcyjnego dopiero po zakończeniu programowania Antywzorzec: ręczne zarządzanie konfiguracją środowiska produkcyjnego Czy możemy to poprawić? Jak mamy osiągnąć nasz cel? Każda zmiana powinna uruchamiać proces pozyskiwania informacji zwrotnej Informacja zwrotna musi być uzyskiwana możliwie szybko Zespół odpowiedzialny za wdrożenie musi wyciągnąć praktyczne wnioski z otrzymanej informacji zwrotnej Czy ten proces się skaluje? Jakie płyną z tego korzyści? Przyznanie zespołom większej władzy Ograniczenie liczby błędów Obniżenie poziomu stresu Elastyczność wdrożenia Ćwiczenie czyni mistrza Kandydat do wydania Każde zaewidencjonowanie prowadzi do potencjalnego wydania Zasady dostarczania oprogramowania Stwórz powtarzalny, niezawodny proces dostarczania oprogramowania Automatyzuj, co tylko się da Przechowuj wszystko w systemie kontroli wersji Jeśli to boli, rób to częściej i szybciej zmierz się z bólem Wbuduj jakość w proces wytwarzania Gotowe oznacza wydane Wszyscy są odpowiedzialni za udostępnianie oprogramowania Ciągłe doskonalenie Zarządzanie konfiguracją Stosowanie systemów kontroli wersji W systemie kontroli wersji przechowuj absolutnie wszystko Wprowadzaj zmiany regularnie do głównej gałęzi projektu Posługuj się czytelnymi opisami zakresu zmian Zarządzanie zależnościami Zarządzanie bibliotekami zewnętrznymi Zarządzanie modułami Zarządzanie konfiguracją oprogramowania Konfiguracja i elastyczność Typy konfiguracji Zarządzanie konfiguracją aplikacji Zarządzanie konfiguracją szeregu aplikacji Zasady zarządzania konfiguracją aplikacji Zarządzanie środowiskami Narzędzia do zarządzania środowiskami Zarządzanie procesem zmiany Ciągła integracja Wdrażanie ciągłej integracji Czego potrzebujesz na początek? Podstawowy system ciągłej integracji Warunki wstępne ciągłej integracji Ewidencjonuj regularnie Stwórz obszerny i kompleksowy zestaw zautomatyzowanych testów Niech proces kompilacji i testowania będzie możliwie krótki Zarządzanie środowiskiem programistycznym Stosowanie systemów ciągłej integracji Podstawowa funkcjonalność Wodotryski Kluczowe praktyki Nie ewidencjonuj niczego w popsutej kompilacji Zawsze testuj lokalnie wszystkie zmiany przed ich zatwierdzeniem albo zleć to serwerowi CI Zanim podejmiesz pracę, poczekaj na powodzenie testów towarzyszących przekazywaniu zmian Nigdy nie idź do domu, dopóki kompilacja nie działa poprawnie Zawsze bądź przygotowany na powrót do poprzednich wersji Ustaw sobie limit czasu na poprawki przed cofnięciem zmian Nie wyłączaj testów, które zakończyły się niepowodzeniem Weź odpowiedzialność za wszystkie szkody powstałe w wyniku zmian Programowanie sterowane testami Zalecane praktyki Praktyki programowania ekstremalnego (XP) Odrzucanie kompilacji ze względu na naruszenie architektury Odrzucanie kompilacji ze względu na powolność testów Odrzucanie kompilacji ze względu na ostrzeżenia i niewłaściwe formatowania kodu Zespoły rozproszone Wpływ na proces Scentralizowana ciągła integracja Problemy techniczne Podejścia alternatywne Rozproszone systemy kontroli wersji Wdrożenie strategii testów Typy testów Testy biznesowe wspierające proces wytwarzania oprogramowania Testy technologiczne wspierające programowanie Testy biznesowe umożliwiające krytyczną analizę projektu Testy technologiczne umożliwiające krytyczną analizę projektu Obiekty zastępcze Sytuacje i strategie z prawdziwego życia Na początku projektu W środku projektu Kod zastany Testy integracyjne Proces Zarządzanie zaległymi błędami POTOK WDROŻEŃ Anatomia potoku wdrożeń Czym jest potok wdrożeń? Podstawowy potok wdrożeń Praktyki związane z potokiem wdrożeń Kompiluj binaria tylko raz W każdym środowisku wdrażaj w taki sam sposób Testuj wdrożenia testami dymnymi Wdrażaj na kopii środowiska produkcyjnego Każda zmiana powinna być natychmiast przekazywana do kolejnej fazy potoku Jeśli jakakolwiek część potoku nie działa, zatrzymaj potok Faza przekazywania zmian Najlepsze praktyki fazy przekazywania zmian Bramka automatycznych testów akceptacyjnych Najlepsze praktyki fazy zautomatyzowanych testów akceptacyjnych Kolejne fazy testowania Testy ręczne Testy niefunkcjonalne Przygotowanie do wydania Automatyzacja wdrożenia i wydania Wycofywanie się ze zmian Budowanie na sukcesie Implementacja potoku wdrożeń Tworzenie modelu strumienia wartości i szkieletu systemu Automatyzacja procesu kompilacji i wdrażania Automatyzacja testów jednostkowych i analiza kodu Automatyzacja testów akceptacyjnych Rozwijanie potoku Miary Skrypty kompilacji i wdrożenia Przegląd narzędzi kompilacji Make Ant NAnt i MSBuild Maven Rake Buildr Psake Reguły i praktyki pisania skryptów kompilacji i wdrożenia Stwórz skrypt dla każdej fazy potoku wdrożeń Zastosuj właściwą technologię do wdrożenia aplikacji W każdym środowisku wdrażaj za pomocą tych samych skryptów Skorzystaj z systemu zarządzania pakietami systemu operacyjnego Zapewnij idempotentność procesu wdrożenia Rozwijaj system wdrożeniowy przyrostowo Struktura projektu dla aplikacji, których celem jest wirtualna maszyna Javy Układ projektu Tworzenie skryptów wdrożenia Wdrażanie i testowanie warstw Testowanie konfiguracji środowiska Rady i wskazówki Zawsze stosuj ścieżki względne Wyeliminuj etapy ręczne Wbuduj możliwość prześledzenia drogi od binariów do systemu kontroli wersji Nie ewidencjonuj binariów w systemie kontroli wersji jako części kompilacji Cele testowe nie powinny eliminować kompilacji Ogranicz aplikację za pomocą zintegrowanych testów dymnych Porady i wskazówki dotyczące .NET Faza przekazywania zmian Zasady i praktyki fazy przekazywania zmian Dostarczaj szybkiej i użytecznej informacji zwrotnej Co powinno przerywać fazę przekazywania zmian? Nadzoruj uważnie fazę przekazywania zmian Przekaż odpowiedzialność programistom W bardzo dużych zespołach przypisz komuś funkcję mistrza kompilacji Wyniki fazy przekazywania zmian Repozytorium artefaktów Zasady i praktyki dotyczące zestawu testów fazy przekazywania zmian Unikaj interfejsu użytkownika Stosuj wstrzykiwanie zależności Unikaj bazy danych Przy testach jednostkowych unikaj asynchroniczności Wykorzystywanie obiektów zastępczych Minimalizacja stanu w testach Pozorowanie czasu Nic na siłę Zautomatyzowane testy akceptacyjne Dlaczego zautomatyzowane testy akceptacyjne są tak ważne?) Jak tworzyć zestawy poddających się utrzymaniu testów akceptacyjnych? Testowanie graficznego interfejsu użytkownika Tworzenie testów akceptacyjnych Rola analityków i testerów Analiza w projektach iteracyjnych Kryteria akceptacyjne jako wykonywalne specyfikacje Warstwa sterownika aplikacji Jak wyrażać swoje kryteria akceptacyjne? Wzorzec sterownika okna: uniezależnianie testów od GUI Implementacja testów akceptacyjnych Stan w testach akceptacyjnych Ograniczenia procesu, hermetyzacja i testowanie Zarządzanie asynchronicznością i przekroczeniem czasu przyznanego na daną operację Stosowanie obiektów zastępczych Faza testów akceptacyjnych Utrzymywanie poprawności testów akceptacyjnych Testy wdrożenia Wydajność testów akceptacyjnych Refaktoryzacja często wykonywanych zadań Współdziel kosztowne zasoby Testowanie równoległe Stosowanie przetwarzania rozproszonego Testowanie wymagań niefunkcjonalnych Zarządzanie wymaganiami niefunkcjonalnymi Analiza wymagań niefunkcjonalnych Programowanie z myślą o wydajności Pomiar wydajności Jak definiować sukces i porażkę w testach wydajnościowych? Środowisko testów wydajnościowych Automatyzacja testów wydajnościowych Testowanie wydajności poprzez interfejs użytkownika Nagrywanie interakcji przez usługę lub publiczne API Stosowanie szablonów nagranych interakcji Stosowanie stubów testów wydajnościowych do produkcji testów Dodawanie testów wydajnościowych do potoku wdrożeń Dodatkowe korzyści płynące z systemu testów wydajnościowych Wdrażanie i wydawanie aplikacji Tworzenie strategii udostępniania oprogramowania Plan wydania Udostępnianie produktów użytkownikom Wdrażanie i promocja aplikacji Pierwsze wdrożenie Szkicowanie procesu udostępniania oprogramowania i promowania kompilacji Promocja konfiguracji Orkiestracja Wdrożenia w środowiskach tymczasowych Wycofywanie się z wdrożeń i wydania bez przestojów Wycofywanie się poprzez powtórne wdrożenie wcześniejszej dobrej wersji Wydanie bez przestoju Wdrożenia niebiesko-zielone Wydanie kanarkowe Poprawki awaryjne Ciągłe wdrażanie Ciągłe udostępnianie oprogramowania instalowanego przez użytkownika Rady i wskazówki Ludzie odpowiedzialni za wdrożenie powinni być zaangażowani w tworzenie procesu wdrożenia Loguj działania związane z wdrożeniem Nie kasuj starych plików, tylko je przenieś Za wdrożenie odpowiada cały zespół Aplikacje serwerowe nie powinny mieć interfejsu graficznego Przy nowym wdrożeniu pamiętaj o rozgrzewce Szybko odrzucaj błędne wersje Nie dokonuj zmian bezpośrednio w środowisku produkcyjnym EKOSYSTEM DOSTARCZANIA OPROGRAMOWANIA Zarządzanie środowiskami i infrastrukturą Rozumienie potrzeb zespołu eksploatacji systemów IT Dokumentacja i audyt Ostrzeżenia o nienormalnych zdarzeniach Planowanie ciągłości dostarczania usług IT Korzystaj z technologii znanej zespołowi eksploatacji systemów IT Opracowywanie modelu infrastruktury i zarządzanie nią Kontrola dostępu do infrastruktury Wprowadzanie zmian w infrastrukturze Zarządzanie dostarczaniem i konfiguracją serwerów Dostarczanie serwerów Bieżące zarządzanie serwerami Zarządzanie konfiguracją middleware'u Zarządzanie konfiguracją Zbadaj produkt Przeanalizuj, w jaki sposób middleware obsługuje stan Poszukaj API konfiguracji Zastosuj lepszą technologię Zarządzanie usługami infrastrukturalnymi Systemy wieloadresowe Wirtualizacja Zarządzanie środowiskami wirtualnymi Środowiska wirtualne i potok wdrożeń Wysoce równoległe testowanie ze środowiskami wirtualnymi Przetwarzanie w chmurze Infrastruktura w chmurze Platformy w chmurze Jedno rozwiązanie nie musi być odpowiednie dla wszystkich Krytyka przetwarzania w chmurze Monitorowanie infrastruktury i aplikacji Gromadzenie danych Rejestrowanie zdarzeń Tworzenie tablic wskaźników Monitoring sterowany zachowaniami Zarządzanie danymi Pisanie skryptów baz danych Inicjalizacja baz danych Zmiana przyrostowa Wersjonowanie bazy danych Zarządzanie zharmonizowanymi zmianami Wycofywanie się do poprzedniej wersji baz danych i wydania bez przestojów Wycofywanie się bez utraty danych Uniezależnianie wdrożenia aplikacji od migracji bazy danych Zarządzanie danymi testowymi Imitowanie bazy danych na potrzeby testów jednostkowych Zarządzanie zależnościami między testami a danymi Izolacja testu Przygotowanie i rozmontowanie Spójne scenariusze testowe Zarządzanie danymi i potok wdrożeń Dane w fazie przekazywania zmian Dane w testach akceptacyjnych Dane w testach wydajnościowych Dane w innych fazach testów Zarządzanie modułami i zależnościami Utrzymywanie aplikacji w stanie zdatności do wydania Ukryj nową funkcjonalność, dopóki nie zostanie ukończona Wprowadzaj wszystkie zmiany przyrostowo Rozgałęzianie przez abstrakcję Zależności Piekło zależności Zarządzanie bibliotekami Moduły Jak dzielić bazę kodu na moduły? Droga modułów przez potok wdrożeń Potok integracyjny Zarządzanie schematem zależności Tworzenie schematów zależności Potokowanie schematów zależności Kiedy powinniśmy wyzwalać kompilacje? Ostrożny optymizm Zależności cykliczne Zarządzanie binariami Jak powinno działać repozytorium artefaktów? W jaki sposób potok wdrożeń powinien współdziałać z repozytorium artefaktów? Zarządzanie zależnościami za pomocą Mavena Refaktoryzacja zależności Mavena Zaawansowana kontrola wersji Krótka historia kontroli wersji CVS Subversion Komercyjne systemy kontroli wersji Wyłącz pesymistyczne blokowanie Rozgałęzianie i scalanie Scalanie Gałęzie, strumienie i ciągła integracja Rozproszone systemy kontroli wersji Czym jest rozproszony system kontroli wersji? Krótka historia rozproszonego systemu kontroli wersji Rozproszone systemy kontroli wersji w środowiskach korporacyjnych Korzystanie z rozproszonych systemów kontroli wersji Strumieniowe systemy kontroli wersji Czym są strumieniowe systemy kontroli wersji? Modele wytwarzania oprogramowania z wykorzystaniem strumieni Widoki statyczne i dynamiczne Ciągła integracja z systemami kontroli wersji opartymi na strumieniach Programuj na gałęzi głównej projektu Dokonywanie złożonych zmian bez rozgałęziania Gałąź na potrzeby wydania Rozgałęzienia według kryterium funkcji Rozgałęzianie pod kątem zespołu Zarządzanie ciągłym dostarczaniem oprogramowania Model dojrzałości zarządzania konfiguracją i wydaniami Jak posługiwać się modelem dojrzałości Cykl życia projektu Identyfikacja Zapoczątkowywanie Inicjalizacja Wytwarzanie i wdrażanie Eksploatacja Proces zarządzania ryzykiem Podstawy zarządzania ryzykiem Harmonogram zarządzania ryzykiem Jak wykonać ćwiczenie z zakresu zarządzania ryzykiem? Częste problemy z dostarczaniem oprogramowania - objawy i przyczyny Rzadkie lub wadliwe wdrożenia Kiepska jakość aplikacji Kiepsko zarządzany proces ciągłej integracji Słabe zarządzanie konfiguracją Zgodność z regulacjami i audyt Przewaga automatyzacji nad dokumentacją Narzucanie możliwości śledzenia zmian Praca w silosach Zarządzanie zmianą
Sygnatura czytelni BWEAiI: XII J 51
Ta pozycja znajduje się w zbiorach 2 placówek. Rozwiń listę, by zobaczyć szczegóły.
Wypożyczalnia
Są egzemplarze dostępne do wypożyczenia: sygn. 145213, 145237 (2 egz.)
Biblioteka WEAiI
Egzemplarze są dostępne wyłącznie na miejscu w bibliotece: sygn. 139862 N (1 egz.)
Pozycja została dodana do koszyka. Jeśli nie wiesz, do czego służy koszyk, kliknij tutaj, aby poznać szczegóły.
Nie pokazuj tego więcej

Deklaracja dostępności