Używamy cookies, aby ułatwić korzystanie z Portalu. Możesz określić warunki przechowywania, dostępu do plików cookies w Twojej przeglądarce. Dowiedz się więcej.
strona główna Strona główna | Nowości | Promocje | Zapowiedzi Twoje konto | Zarejestruj | Schowek | Kontakt | Pomoc
mapa działów
Szukaj: szukanie zaawansowane
Koszyk
Książki \ Programowanie \ Agile

Architektura Lean w projektach Agile Język: 1

978-83-246-8672-8

Cena Brutto: 59.00

Cena netto: 56.19

Ilość:
Wersja: Drukowana
Autor James O. Coplien, Gertrud Bjornvig
Liczba_stron 320
Wydawnictwo Helion
Oprawa miękka
Data_Wydania 2014-05-23
Architektura Lean w projektach

Agile



Prędkość z jaką rozwijają się aplikacje wymusza stosowanie elastycznych sposobów wytwarzania oprogramowania. Podręcznik ten opisuje architekturę Lean, która usprawni ten proces dzięki nowatorskiemu podejściu. Dzięki Lean Twoja aplikacja zyska zmiany funkcjonalne, tak aby jej użytkownicy mogli w pełni wykorzystać jej możliwości.


Książka wprowadzi Cię w świat Agile i Lean dzięki czemu przydzielisz najważniejsze role członkom projektu. Dowiesz się, czym jest system, jak podzielić projekt na części i dokonać wyboru jego stylu. W następnej kolejności zorganizujesz swój kod i przetestujesz stworzoną architekturę. Podręcznik przedstawia przykłady, które w idealny sposób przedstawiają założenia architektury Lean, z dużym naciskiem na sam kod. Jest to obowiązkowa lektura dla wszystkich programistów i projektantów systemów informatycznych.


Z tą książką:

  • zapoznasz się z filozofią Agile i Lean
  • napiszesz kod odporny na zmiany
  • rozszyfrujesz paradygmat DCI
  • opanujesz współczesne metody tworzenia oprogramowania


Pragniemy Państwa zapewnić, iż dokładamy wszelkich możliwych starań, by opisy książek i podręczników, zawarte na naszych stronach internetowych, zawierały bieżące i wiarygodne materiały. Może jednak, mimo naszych wysiłków, w opisy książek wkraść się przekłamanie z naszej strony niezamierzone. Nie może to stanowić powodu do roszczeń. O ile macie Państwo jakiekolwiek pytania lub wątpliwości - prosimy o kontakt z naszym ekspertem lub działem handlowym. Postaramy  się odpowiedzieć na wszystkie Państwa pytania zanim podejmiecie Państwo decyzje o złożeniu zamówienia.


O autorach (11)
Wstęp (13)
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) Bibliografia (307) Skorowidz (317)
powrót
 
Produkty Podobne
Agile. Retrospektywy w zarządzaniu standardami
Agile. Rusz głową!
Agile. Metodyki zwinne w planowaniu projektów
Agile Application Lifecycle Management: Using DevOps to Drive Process Improvement
Common Information Models for an Open, Analytical, and Agile World
Agile Project Management with Kanban
More Agile Testing: Learning Journeys for the Whole Team
Architektura Lean w projektach Agile
Agile. Szybciej, łatwiej, dokładniej
Zrozumieć Agile Project Management. Równowaga kontroli i elastyczności
Więcej produktów