Zaawansowane wyszukiwanie
  Strona Główna » Sklep » Algorytmy Wzorce UML » Techniki programowania » Moje Konto  |  Zawartość Koszyka  |  Do Kasy   
 Wybierz kategorię
Algorytmy Wzorce UML
  Algorytmy
  Deep Learning Uczenie maszynowe
  Inżynieria oprogramowania
  Scrum
  Sztuczna inteligencja
  Techniki programowania
  Wyrażenia regularne
  Wzorce projektowe
  Zarządzanie projektami
Bazy danych
Bezpieczeństwo
Bioinformatyka
Biznes Ekonomia Firma
Chemia
DTP Design
E-biznes
Ekonometria
Elektronika Elektrotechnika
Energetyka
Fizyka
GIS
Grafika użytkowa
Hardware
Informatyczne systemy zarządzania
Informatyka w szkole
Języki programowania
Matematyka
Multimedia
Obsługa komputera
Office
Poradniki
Programowanie gier
Programy inżynierskie
Programy matematyczne
Słowniki
Serwery
Sieci komputerowe
Systemy operacyjne
Technika
Telekomunikacja
Tworzenie stron WWW

Zobacz pełny katalog »
 Wydawnictwo:
 APN Promise
Poznaj Microsoft Power BI Przekształcanie danych we wnioski

Poznaj Microsoft Power BI Przekształcanie danych we wnioski

79.80zł
63.84zł
Architektura Lean w projektach Agile 59.00zł 44.25zł
Architektura Lean w projektach Agile

Tytuł: Architektura Lean w projektach Agile
Autor: James O. Coplien, Gertrud Bjornvig
ISBN: 978-83-246-8672-8
Ilość stron: 320
Data wydania: 05/2014
Format: 168x237
Wydawnictwo: Helion
Cena: 59.00zł 44.25zł


Programuj i organizuj kod z metodyką Lean!

Tempo rozwoju aplikacji wymusza stosowanie elastycznych sposobów wytwarzania oprogramowania. Książka ta została poświęcona architekturze Lean, która usprawni ten proces dzięki nowatorskiemu podejściu. Wykorzystaj je i przygotuj swoją aplikację na zmiany funkcjonalne, by użytkownicy mogli w pełni wykorzystać jej potencjał!

W trakcie lektury zapoznasz się z duchem Agile i Lean oraz przydzielisz najważniejsze role członkom projektu. Po tym niezwykle interesującym wstępie rozpoczniesz pasjonującą podróż po świecie architektury Lean. Dowiesz się, czym jest system, jak podzielić projekt na części i wybrać jego styl.

W kolejnych rozdziałach zorganizujesz swój kod i przetestujesz zaprojektowaną architekturę. Znajdziesz tu wiele przykładów, które w najlepszy sposób przedstawiają założenia i intencje architektury Lean, z dużym naciskiem na sam kod. To obowiązkowa lektura dla wszystkich programistów i projektantów systemów informatycznych.

Dzięki tej książce:
• poznasz filozofię Agile i Lean
• zbudujesz kod odporny na zmiany
• zrozumiesz paradygmat DCI
• poznasz współczesne metody wytwarzania oprogramowania!

Twój przewodnik po architekturze Lean.

Spis treści:

1. Wprowadzenie (19)

  • 1.1. Podwaliny: Lean i Agile (19)
  • 1.2. Architektura Lean i wytwarzanie funkcji zgodnie z metodyką Agile (22)
  • 1.3. Produkcja Agile (24)
    • 1.3.1. Agile bazuje na architekturze Lean (24)
    • 1.3.2. Zakres systemów Agile (25)
    • 1.3.3. Agile i DCI (26)
  • 1.4. Książka w bardzo małej pigułce (27)
  • 1.5. Lean i Agile: kontrastujące i uzupełniające (28)
    • 1.5.1. Sekret Lean (30)
  • 1.6. Utracone praktyki (30)
    • 1.6.1. Architektura (31)
    • 1.6.2. Obsługa zależności pomiędzy wymaganiami (31)
    • 1.6.3. Podstawy użyteczności (31)
    • 1.6.4. Dokumentacja (32)
    • 1.6.5. Zdrowy rozsądek, myślenie i opieka (35)
  • 1.7. O czym ta książka nie jest? (36)
  • 1.8. Agile, Lean, Scrum i inne metodologie (37)
  • 1.9. Rys historyczny (38)

2 . Produkcja Agile w pigułce (41)

  • 2.1. Zaangażuj interesariuszy (41)
  • 2.2. Zdefiniowanie problemu (43)
  • 2.3. Czym system jest: podstawa formy (43)
  • 2.4. Czym system jest: siła napędowa systemu (45)
  • 2.5. Projekt i kodowanie (46)
  • 2.6. Odliczanie: 3, 2, 1... (47)

3. Zaangażowanie interesariuszy (49)

  • 3.1. Strumień wartości (49)
    • 3.1.1. Użytkownicy końcowi i inni interesariusze jako kotwice strumienia wartości (50)
    • 3.1.2. Architektura w ramach strumienia wartości (51)
    • 3.1.3. Sekret Lean (52)
  • 3.2. Najważniejsi interesariusze (54)
    • 3.2.1. Użytkownicy docelowi (56)
    • 3.2.2. Biznes (60)
    • 3.2.3. Klienci (61)
    • 3.2.4. Eksperci dziedzinowi (64)
    • 3.2.5. Deweloperzy i testerzy (66)
  • 3.3. Elementy procesu angażowania interesariuszy (68)
    • 3.3.1. Od czego zacząć? (68)
    • 3.3.2. Zaangażowanie klienta (70)
  • 3.4. Sieć interesariuszy: eliminowanie marnotrawstwa czasu (71)
    • 3.4.1. Linia produkcyjna czy rój? (71)
    • 3.4.2. Pierwsza rzecz, którą należy zbudować (73)
    • 3.4.3. Utrzymuj jedność zespołu (74)
  • 3.5. Nie ma szybkich rozwiązań, ale jest nadzieja (75)

4. Definiowanie problemu (77)

  • 4.1. Jakie cechy Agile mają definicje problemów? (78)
  • 4.2. Jakie cechy Lean mają definicje problemów? (78)
  • 4.3. Dobre i złe definicje problemów (79)
  • 4.4. Problemy i rozwiązania (81)
  • 4.5. Proces definiowania problemów (82)
    • 4.5.1. Ceń bardziej polowanie niż nagrodę (82)
    • 4.5.2. Własność problemu (83)
    • 4.5.3. Przerost funkcjonalności (84)
  • 4.6. Definicje problemu, cele, czartery, wizje i zamierzenia (84)
  • 4.7. Dokumentacja? (85)

5. Czym jest system? Część I. Architektura Lean (87)

  • 5.1. Kilka niespodzianek o architekturze (88)
    • 5.1.1. Co Lean ma z tym wspólnego? (90)
    • 5.1.2. Co Agile ma wspólnego z architekturą? (91)
  • 5.2. Pierwszy krok w projekcie: podział na części (94)
    • 5.2.1. Pierwszy podział: forma dziedzinowa a forma behawioralna (95)
    • 5.2.2. Drugi podział: prawo Conwaya (96)
    • 5.2.3. Rzeczywista złożoność podziału systemu (98)
    • 5.2.4. Wymiary złożoności (99)
    • 5.2.5. Dziedziny. Wyjątkowy podział (99)
    • 5.2.6. Wracamy do wymiarów złożoności (101)
    • 5.2.7. Architektura i kultura (104)
    • 5.2.8. Wnioski na temat prawa Conwaya (105)
  • 5.3. Drugi krok w projekcie: wybór stylu projektu (105)
    • 5.3.1. Struktura a podział (106)
    • 5.3.2. Podstawy stylu: części stałe i zmienne (107)
    • 5.3.3. Zaczynamy od oczywistych części wspólnych i różnic (108)
    • 5.3.4. Części wspólne, różnice i zakres (111)
    • 5.3.5. Jawne wyrażanie części wspólnych i różnic (113)
    • 5.3.6. Najpopularniejszy styl: programowanie obiektowe (116)
    • 5.3.7. Inne style w obrębie świata von Neumanna (118)
    • 5.3.8. Języki dziedzinowe i generatory aplikacji (120)
    • 5.3.9. Formy skodyfikowane: języki wzorców (123)
    • 5.3.10. Oprogramowanie dostawców zewnętrznych i inne paradygmaty (124)
  • 5.4. Dokumentacja? (127)
    • 5.4.1. Słownik dziedziny (127)
    • 5.4.2. Przenoszenie architektury (128)
  • 5.5. Tło historyczne (128)

6. Czym jest system? Część II. Kodowanie (131)

  • 6.1. Krok trzeci: szkic kodu (131)
    • 6.1.1. Abstrakcyjne klasy bazowe (132)
    • 6.1.2. Warunki wstępne, warunki końcowe i asercje (136)
    • 6.1.3. Skalowanie algorytmów: druga strona statycznych asercji (142)
    • 6.1.4. Forma a dostępne usługi (143)
    • 6.1.5. Rusztowanie (144)
    • 6.1.6. Testowanie architektury (146)
  • 6.2. Relacje w architekturze (149)
    • 6.2.1. Typy relacji (149)
    • 6.2.2. Testowanie relacji (150)
  • 6.3. Programowanie obiektowe "po nowemu" (151)
  • 6.4. Ile architektury? (153)
    • 6.4.1. Równowaga pomiędzy BUFD a YAGNI (154)
    • 6.4.2. Jeden rozmiar nie pasuje wszystkim (154)
    • 6.4.3. Kiedy architektura jest gotowa? (156)
  • 6.5. Dokumentacja? (156)
  • 6.6. Tło historyczne (157)

7. Co system robi: funkcje systemu (159)

  • 7.1. Co system robi? (160)
    • 7.1.1. Opowieści użytkowników: początek (160)
    • 7.1.2. Wykorzystanie specyfikacji i przypadków użycia (161)
    • 7.1.3. Pomoc należy się także programistom (162)
    • 7.1.4. Kilometraż nie zawsze jest taki sam (163)
  • 7.2. Kto będzie korzystać z naszego oprogramowania? (164)
    • 7.2.1. Profile użytkowników (164)
    • 7.2.2. Osoby (164)
    • 7.2.3. Profile użytkowników czy osoby? (165)
    • 7.2.4. Role użytkowników i terminologia (165)
  • 7.3. Do czego użytkownicy chcą wykorzystać nasze oprogramowanie? (166)
    • 7.3.1. Lista własności (166)
    • 7.3.2. Diagramy przepływu danych (166)
    • 7.3.3. Osoby i scenariusze (167)
    • 7.3.4. Narracje (167)
    • 7.3.5. Projektowanie aplikacji sterowane zachowaniami (167)
    • 7.3.6. Teraz, gdy jesteśmy rozgrzani... (168)
  • 7.4. Dlaczego użytkownicy chcą korzystać z naszego oprogramowania? (169)
  • 7.5. Konsolidacja tego, co system robi (170)
    • 7.5.1. Widok helikoptera (172)
    • 7.5.2. Ustawianie sceny (177)
    • 7.5.3. Odtwarzanie scenariusza słonecznego dnia (178)
    • 7.5.4. Dodawanie interesujących rzeczy (183)
    • 7.5.5. Od przypadków użycia do ról (191)
  • 7.6. Podsumowanie (193)
    • 7.6.1. Wsparcie przepływu pracy użytkowników (193)
    • 7.6.2. Wsparcie dla testów blisko prac rozwojowych (193)
    • 7.6.3. Wsparcie dla wydajnego podejmowania decyzji na temat funkcjonalności (194)
    • 7.6.4. Wsparcie dla nowo powstających wymagań (odchyleń) (194)
    • 7.6.5. Wsparcie dla planowania wydań (194)
    • 7.6.6. Uzyskanie danych wejściowych do opracowania architektury (195)
    • 7.6.7. Budowanie w zespole zrozumienia przedmiotu pracy (195)
  • 7.7. "To zależy": kiedy przypadki użycia nie są dobre? (196)
    • 7.7.1. Klasyczne programowanie obiektowe: architektury atomowych zdarzeń (196)
  • 7.8. Testowanie użyteczności (197)
  • 7.9. Dokumentacja? (198)
  • 7.10. Tło historyczne (200)

8. Kodowanie: podstawowy montaż (201)

  • 8.1. Obraz z góry: wzorzec projektowy Model-View-Controller-User (201)
    • 8.1.1. Czym jest program? (202)
    • 8.1.2. Czym jest program Agile? (203)
    • 8.1.3. MVC bardziej szczegółowo (204)
    • 8.1.4. MVC-U: to nie koniec opowieści (205)
  • 8.2. Forma i architektura systemów zdarzeń atomowych (208)
    • 8.2.1. Obiekty dziedziny (208)
    • 8.2.2. Role obiektów, interfejsy i Model (208)
    • 8.2.3. Refleksje: przypadki użycia, architektury zdarzeń atomowych i algorytmy (211)
    • 8.2.4. Przypadek specjalny: odwzorowanie ról obiektów na obiekty typu jeden do wielu (212)
  • 8.3. Aktualizacja logiki dziedziny: rozwijanie metod, faktoryzacja i refaktoryzacja (212)
    • 8.3.1. Tworzenie nowych klas i wypełnianie istniejących namiastek funkcji (213)
    • 8.3.2. Powrót do przyszłości: po prostu stare, dobre programowanie obiektowe (215)
    • 8.3.3. Narzędzia analizy i projektowania (215)
    • 8.3.4. Faktoryzacja (216)
    • 8.3.5. Uwaga na refaktoryzację (216)
  • 8.4. Dokumentacja? (217)
  • 8.5. Do czego te wszystkie artefakty? (217)
  • 8.6. Tło historyczne (218)

9. Kodowanie: architektura DCI (219)

  • 9.1. Czasami inteligentne obiekty po prostu są niewystarczające (219)
  • 9.2. DCI w pigułce (220)
  • 9.3. Przegląd architektury DCI (221)
    • 9.3.1. Części modelu mentalnego użytkownika końcowego, o których zapomnieliśmy (221)
    • 9.3.2. Wprowadzenie ról obiektowych z metodami (223)
    • 9.3.3. Sztuczki z cechami (225)
    • 9.3.4. Klasy kontekstu: jedna w każdym przypadku użycia (226)
  • 9.4. DCI na przykładzie (229)
    • 9.4.1. Dane wejściowe do projektu (229)
    • 9.4.2. Od przypadków użycia do algorytmów (230)
    • 9.4.3. Bezmetodowe role obiektów: framework dla identyfikatorów (232)
    • 9.4.4. Podział algorytmów pomiędzy role obiektowe z metodami (234)
    • 9.4.5. Framework kontekstu (241)
    • 9.4.6. Warianty i sztuczki w architekturze DCI (259)
  • 9.5. Aktualizacja logiki dziedziny (261)
    • 9.5.1. Porównanie DCI ze stylem architektury zdarzeń atomowych (261)
    • 9.5.2. Szczególne aspekty logiki dziedzinowej w architekturze DCI (263)
  • 9.6. Obiekty kontekstu w modelu mentalnym użytkownika końcowego: rozwiązanie odwiecznego problemu (265)
  • 9.7. Do czego te wszystkie artefakty? (269)
  • 9.8. Nie tylko C++: DCI w innych językach (272)
    • 9.8.1. Scala (272)
    • 9.8.2. Python (273)
    • 9.8.3. C# (273)
    • 9.8.4. ...a nawet w Javie (273)
    • 9.8.5. Przykład z rachunkami w Smalltalku (274)
  • 9.9. Dokumentacja? (274)
  • 9.10. Tło historyczne (275)
    • 9.10.1. DCI a programowanie aspektowe (275)
    • 9.10.2. Inne podejścia (276)

10. Epilog (277)

A. Implementacja przykładu architektury DCI w Scali (279)

B. Przykład implementacji rachunków w Pythonie (283)

C. Przykład implementacji rachunków w C# (287)

D. Przykład implementacji rachunków w Ruby (291)

E. Qi4j (297)

F. Przykład implementacji rachunków w Squeaku (299)


Najniższa cena z 30 dni przed obniżką 44,25zł

Architektura Lean w projektach Agile
Tytuł książki: "Architektura Lean w projektach Agile"
Autor: James O. Coplien, Gertrud Bjornvig
Wydawnictwo: Helion
Cena: 59.00zł 44.25zł
Klienci, którzy kupili „Architektura Lean w projektach Agile”, kupili także:

Fizyka zjawisk radiestezyjnych. Teoria i praktyka, Włodzimierz Ryszard Łazowski, Wydawnictwo Studio Astropsychologii

Wybrane algorytmy optymalizacji, Marian Chudy, Wydawnictwo EXIT

UMTS System telefonii komórkowej trzeciej generacji Wydanie 2, Jerzy Kołakowski, Jacek Cichocki, Wydawnictwo WKiŁ

Projektowanie złożonych układów cyfrowych, Marek Pawłowski, Andrzej Skorupski, Wydawnictwo WKiŁ

Klimatyczna katastrofa, Anthony Giddens, Wydawnictwo Prószyński

Zjawiska na niebie gwiaździstym Jak obserwować i rozumieć ruchy ciał niebieskich, Walter Kraul, Wydawnictwo Impuls

Uczenie maszynowe w Pythonie. Receptury, Chris Albon, Wydawnictwo Helion

Strategiczny brand marketing. Praktyczny poradnik skutecznego marketingu dla menedżerów i nie tylko. Wydanie II poszerzo, Jarek Szczepański, Wydawnictwo Onepress

Neurobiologia Krótkie wykłady, Alan Longstaff, Wydawnictwo Naukowe PWN

piątek, 29 marca 2024   Mapa strony |  Nowości |  Dzisiejsze promocje |  Koszty wysyłki |  Kontakt z nami