reklama - zainteresowany?

Head First Software Development. Edycja polska - Helion

Head First Software Development. Edycja polska
Autor: Dan Pilone, Russ Miles
Tytuł oryginału: Head First Software Development
Tłumaczenie: Tomasz Walczak
ISBN: 978-83-246-1547-6
stron: 472, Format: 200x230, okładka: miękka
Data wydania: 2008-11-05
Księgarnia: Helion

Cena książki: 69,00 zł

Dodaj do koszyka Head First Software Development. Edycja polska

Tagi: Programowanie | programowanie-kupon | Techniki programowania

Opanuj niezwykłą sztukę wytwarzania oprogramowania!

  • W jaki sposób zadowolić klienta?
  • Jak wygląda proces wytwarzania oprogramowania?
  • Jakie pułapki czekają na Ciebie?

Proces wytwarzania oprogramowania -- już sam opis sugeruje trudności. I rzeczywiście -- jest to proces niezwykle złożony. Od samego początku trafiamy na kwestie takie, jak analiza potrzeb klienta i zebranie jego wymagań. Z każdym krokiem wszystko komplikuje się jeszcze bardziej... Konieczna jest implementacja poszczególnych wymagań klienta, testowanie tych rozwiązań, korekta znalezionych błędów. Na to wszystko nakłada się jeszcze konieczność tworzenia różnych wersji rozwiązań i zmienny nastrój klienta. Jak sobie z tym wszystkim poradzić? Jak bezboleśnie i skutecznie przejść przez cały ten proces?

Tylko bez obaw! Oto podręcznik, który dzięki innowacyjnym metodom przekazywania wiedzy sprawi, że szybko zrozumiesz proces wytwarzania oprogramowania i nauczysz się gładko podążać jego wyboistą ścieżką. Autorzy książki "Head First Software Development. Edycja polska" -- Dan i Russ -- pokażą Ci, w jaki sposób zadowolić klienta i zebrać od niego wymagania oraz określić jego potrzeby. Dowiesz się, jak zapanować nad poszczególnymi wersjami Twojego projektu. Nauczysz się prowadzić testy i usuwać błędy. Zdobędziesz informacje dotyczące wytwarzania oprogramowania sterowanego testami, a na koniec zobaczysz, jak taki proces wygląda w rzeczywistości. Wszystkie te informacje przedstawione zostały na licznych ilustracjach, co wydatnie ułatwia przyswajanie wiedzy, dodatkowo przekazanej przystępnym i pełnym humoru językiem. Po lekturze tego podręcznika nawet laik będzie w stanie zarządzać takim procesem!

  • Zbieranie wymagań
  • Planowanie projektu
  • Kontrola wersji
  • Wytwarzanie sterowane testami
  • Testy integracyjne
  • Usuwanie błędów

Tworzenie oprogramowania? Nic prostszego!!!

Dodaj do koszyka Head First Software Development. Edycja polska

 

Osoby które kupowały "Head First Software Development. Edycja polska", wybierały także:

  • Zen Steve'a Jobsa
  • ASP.NET MVC. Kompletny przewodnik dla programistów interaktywnych aplikacji internetowych w Visual Studio
  • jQuery, jQuery UI oraz jQuery Mobile. Receptury
  • Scratch. Komiksowa przygoda z programowaniem
  • Baltie. Kurs video. Poziom pierwszy. Elementarz programowania w języku wizualnym

Dodaj do koszyka Head First Software Development. Edycja polska

Spis treści

Head First Software Development. Edycja polska -- spis treści

Wprowadzenie

  • Dla kogo przeznaczona jest ta książka? (26)
  • Wiemy, co sobie myślisz (27)
  • Metapoznanie: myślenie o myśleniu (29)
  • A oto, co TY możesz zrobić, aby zmusić mózg do posłuszeństwa (31)
  • Przeczytaj koniecznie (32)
  • Zespół recenzentów technicznych (34)
  • Podziękowania (35)

Rozdział 1. Zapewnianie zadowolenia klienta

  • Szlakami Macieja wchodzi do internetu (38)
  • W większości projektów trzeba uwzględnić dwa główne zagadnienia (39)
  • Rozwój oprogramowania metodą wielkiego wybuchu (40)
  • Przenieśmy się w czasie - dwa tygodnie później (41)
  • Rozwój oprogramowania metodą wielkiego wybuchu kończy się zwykle WIELKIMI PROBLEMAMI (42)
  • Doskonały rozwój oprogramowania polega na... (45)
  • Dochodzenie do celu dzięki ITERACJOM (46)
  • Każda iteracja to miniprojekt (50)
  • Każda iteracja prowadzi do rozwoju oprogramowania o WYSOKIEJ JAKOŚCI (50)
  • Klient BĘDZIE zmieniał zdanie (56)
  • Wprowadzenie poprawek to Twoje zadanie (56)
  • Musisz poradzić sobie z POWAŻNYMI problemami... (56)
  • Iteracje automatycznie uwzględniają zmiany (58)
  • Oprogramowanie jest gotowe dopiero w momencie jego UDOSTĘPNIENIA (61)
  • Narzędzia do Twojej programistycznej skrzynki narzędziowej (62)

Rozdział 2. Określanie potrzeb klientów

  • Orbity Oriona przystępują do modernizacji (64)
  • Porozmawiaj z klientem, aby uzyskać WIĘCEJ informacji (67)
  • W obłokach z klientem (68)
  • Czasem sesje bujania w obłokach wyglądają tak jak na rysunku... (70)
  • Dowiedz się, co użytkownicy NAPRAWDĘ robią (71)
  • Wymagania muszą być zorientowane na KLIENTA (73)
  • Rozwijaj wymagania na podstawie informacji zwrotnych od klienta (75)
  • Opowieści użytkownika opisują, CO należy zrealizować w projekcie... a szacunki określają, KIEDY należy to zrobić (77)
  • Rozmowa przy stanowisku pracy (81)
  • Gra w pokera planistycznego (82)
  • Osądź zasadność założeń (85)
  • DŁUGIE w realizacji opowieści użytkownika to ZŁE opowieści użytkownika (88)
  • Celem jest zbieżność (91)
  • Cykl przechodzenia od wymagań do szacunków (94)
  • Na zakończenie można oszacować czas trwania całego projektu (97)
  • Narzędzia do Twojej programistycznej skrzynki narzędziowej (99)

Rozdział 3. Planowanie z myślą o sukcesie

  • Klienci chcą otrzymać oprogramowanie OD RAZU! (102)
  • Określanie priorytetów razem z klientem (105)
  • Wiemy, co znajdzie się w wydaniu 1.0 (prawdopodobnie) (106)
  • Jeśli szacowany czas jest za długi, zmień priorytety (107)
  • Im więcej osób, tym mniej korzyści (109)
  • Dochodzenie do rozsądnego wydania 1.0 (110)
  • Iteracje powinny być krótkie i przyjemne (117)
  • Porównywanie planu z rzeczywistością (119)
  • Szybkość uwzględnia niespodziewane wydarzenia (121)
  • Programiści myślą w kategoriach dni UTOPIJNYCH (122)
  • Twórcy oprogramowania myślą w kategoriach dni REALNYCH (123)
  • Co zrobić, jeśli iteracja jest za długa? (124)
  • Uwzględnij szybkość PRZED zaplanowaniem iteracji (125)
  • Czas na dokonanie oceny (129)
  • Radzenie sobie z wkurzonymi klientami (130)
  • Duża tablica na ścianie (132)
  • Jak zrujnować życie osobiste członków zespołu? (135)
  • Narzędzia do Twojej programistycznej skrzynki narzędziowej (137)

Rozdział 4. Przystępowanie do prawdziwej pracy

  • Poznajemy iSwoon (140)
  • Łączny czas realizacji zadań (143)
  • Uwzględniaj tylko niewykonane zadania (145)
  • Umieszczanie zadań na tablicy (146)
  • Rozpoczynanie pracy nad zadaniami (148)
  • Zadanie jest w toku tylko wtedy, kiedy jest W TOKU (149)
  • Co zrobić, jeśli pracuję jednocześnie nad dwoma zadaniami? (150)
  • Pierwsze spotkanie "na stojaka" (153)
  • Zadanie 1: utworzenie klasy Date (154)
  • Krótkie spotkanie robocze: dzień 5, koniec tygodnia 1 (160)
  • Krótkie spotkanie robocze: dzień 2, tydzień 2 (166)
  • Przerywamy ten rozdział... (170)
  • Musisz kontrolować niezaplanowane zadania (171)
  • Nieoczekiwane prace podwyższają poziom zadań do wykonania (173)
  • Szybkość pomaga, ale... (174)
  • Mamy dużo do zrobienia... (176)
  • ...jednak DOKŁADNIE wiemy, na czym stoimy (177)
  • Wszystko o Szybkości (178)

Rozdział 5. Tworzenie oprogramowania na podstawie doskonałych projektów

  • Zespół pracujący nad iSwoon ma poważne problemy (180)
  • Taki projekt narusza zasadę jednego zadania (183)
  • Wykrywanie wielu obowiązków w projekcie (186)
  • Przechodzenie od wielu obowiązków do jednego zadania (189)
  • Projekt powinien być zgodny z SRP, a także z zasadą DRY (190)
  • Krótkie spotkanie robocze po zakończeniu refaktoryzacji (194)
  • Niezaplanowane zadania to wciąż zadania (196)
  • Częścią Twojego zadania jest przeprowadzenie prezentacji (197)
  • Kiedy wszystko jest gotowe, iteracja jest ukończona (200)

Rozdział 6. Programowanie defensywne

  • Podpisałeś nowy kontrakt na aplikację MuzMachina Pro (206)
  • Praca nad interfejsem GUI (210)
  • Demonstracja nowej MuzMachiny klientowi (213)
  • Zacznijmy od KONTROLI WERSJI (216)
  • Najpierw skonfiguruj projekt... (218)
  • ...a następnie prześlij i pobierz kod (219)
  • Większość narzędzi do kontroli wersji próbuje rozwiązywać problemy za Ciebie (220)
  • Serwer próbuje SCALIĆ zmiany (221)
  • Jeśli system nie potrafi scalić zmian, informuje o konflikcie (222)
  • Następne iteracje, następne opowieści (226)
  • Mamy kilka wersji oprogramowania (228)
  • Opisowe komentarze dodane przy przesyłaniu ułatwiają znalezienie starszego oprogramowania (230)
  • Teraz możesz pobrać wersję 1.0 (231)
  • (Awaryjne) krótkie spotkanie robocze (232)
  • Oznaczanie wersji (233)
  • Oznaczenia, gałęzie, pnie - co jeszcze? (235)
  • Poprawianie wersji 1.0 - tym razem na poważnie (236)
  • Teraz mamy DWIE wersje kodu bazowego (237)
  • Kiedy NIE należy tworzyć gałęzi? (240)
  • Zen poprawnego rozgałęziania (240)
  • Co zapewnia system kontroli wersji... (242)
  • System kontroli wersji nie może sprawdzić, czy kod działa (243)
  • Narzędzia do Twojej programistycznej skrzynki narzędziowej (244)

Rozdział 6.5. Wstaw element a w pole b...

  • Programiści nie potrafią czytać w myślach (248)
  • Budowanie projektu w jednym kroku (249)
  • Ant - narzędzie do budowania projektów w języku Java (250)
  • Projekty, właściwości, cele i zadania (251)
  • Dobre skrypty kompilacji... (256)
  • Dobre skrypty kompilacji wykraczają POZA podstawy (258)
  • Skrypty kompilacji to też kod (260)
  • Nowy, weź dwójkę (261)
  • Narzędzia do Twojej programistycznej skrzynki narzędziowej (262)

Rozdział 7. Pojawiają się problemy

  • ZAWSZE coś pójdzie źle (264)
  • Są trzy sposoby postrzegania systemu (266)
  • Testy czarnej skrzynki dotyczą przede wszystkim danych WEJŚCIOWYCH i WYJŚCIOWYCH (267)
  • Testy szarej skrzynki ZBLIŻAJĄ Cię do kodu (268)
  • Testy białej skrzynki wymagają wiedzy o wnętrzu systemu (271)
  • Testowanie WSZYSTKIEGO w jednym kroku (276)
  • Automatyzacja testów przy użyciu platformy testowej (278)
  • Używanie platformy do uruchamiania testów (279)
  • Sterowanie CI za pomocą narzędzia CruiseControl (282)
  • Testy gwarantują działanie programu, prawda? (284)
  • Przetestowanie całego kodu wymaga sprawdzenia KAŻDEJ GAŁĘZI (292)
  • Użyj raportu pokrycia, aby zobaczyć, które metody są sprawdzane (293)
  • Uzyskanie wysokiego pokrycia kodu nie zawsze jest proste (295)
  • Krótkie spotkanie robocze (297)
  • Narzędzia do Twojej programistycznej skrzynki narzędziowej (300)

Rozdział 8. Zapewnianie poprawności kodu

  • Pisz testy NA POCZĄTKU, a nie na końcu (302)
  • NAJPIERW testy (303)
  • Witamy w świecie wytwarzania sterowanego testami (303)
  • Pierwszy test... (304)
  • ...kończy się całkowitym niepowodzeniem (305)
  • Doprowadź testy do koloru ZIELONEGO (306)
  • Czerwone, zielone, refaktoryzacja... (307)
  • W TDD testy STERUJĄ rozwojem kodu (312)
  • Ukończenie zadania oznacza, że napisałeś wszystkie potrzebne testy i kończą się one sukcesem (314)
  • Kiedy kod przejdzie testy, idź dalej! (315)
  • Prostota oznacza unikanie zależności (319)
  • Zawsze pisz kod, który można przetestować (320)
  • Kiedy wystąpią trudności, przyjrzyj się projektowi (321)
  • Wzorzec strategii pozwala tworzyć wiele wersji jednego interfejsu (322)
  • Przechowuj kod testowy razem z testami (325)
  • Testy prowadzą do powstania lepszego kodu (326)
  • Więcej testów zawsze oznacza więcej kodu (328)
  • Wzorce strategii, luźne powiązanie, zastępowanie obiektów (329)
  • Potrzebujemy wielu odmiennych, choć podobnych obiektów (330)
  • A gdyby tak wygenerować obiekty? (330)
  • Obiekty zastępcze zastępują prawdziwe obiekty (331)
  • Obiekty zastępcze to działające zastępniki obiektów (332)
  • Dobre oprogramowanie można przetestować (335)
  • Niełatwo być zielonym (336)
  • Dzień z życia programisty stosującego TDD (338)
  • Narzędzia do Twojej programistycznej skrzynki narzędziowej (340)

Rozdział 9. Wszystkie elementy łączą się ze sobą...

  • Iteracja jest prawie ukończona... (342)
  • ...jednak możesz zrobić jeszcze wiele rzeczy (343)
  • TRZEBA przeprowadzić testy systemu... (348)
  • ...ale KTO ma to zrobić? (349)
  • Testy systemu wymagają kompletnego oprogramowania (350)
  • Dobre testy systemu wymagają DWÓCH cykli iteracji (351)
  • Więcej iteracji oznacza dodatkowe problemy (352)
  • Życie (i śmierć) błędu (358)
  • Znalazłeś błąd i co dalej? (360)
  • Anatomia raportu o błędzie (361)
  • Jest jeszcze wiele rzeczy, które MÓGŁBYŚ zrobić... (362)
  • Czas na przegląd iteracji (366)
  • Przykładowe pytania z przeglądu iteracji (367)
  • OGÓLNA lista priorytetów zadań DODATKOWYCH (368)
  • Narzędzia do Twojej programistycznej skrzynki narzędziowej (370)

Rozdział 10. Jeśli nie jest zepsute... i tak lepiej to naprawić

  • Czym jest działające oprogramowanie? (372)
  • Potrzebujesz planu następnej iteracji (374)
  • Szybkość pozwala uwzględnić... RZECZYWISTOŚĆ BIZNESOWĄ (381)
  • Klient NADAL jest najważniejszy (382)
  • Oprogramowanie innych zespołów to NADAL tylko oprogramowanie (384)
  • Akceptacja klienta? Jest! (387)
  • Testowanie kodu (392)
  • Houston, mamy problem... (393)
  • Krótkie spotkanie robocze (394)
  • Nie ufaj NIKOMU (395)
  • Zespół bez procesu (400)
  • Zespół z procesem (401)

Rozdział 11. Profesjonalne usuwanie błędów

  • W poprzednim odcinku (404)
  • Najpierw musisz porozmawiać z klientem (406)
  • Pierwszy priorytet: umożliwienie zbudowania oprogramowania (412)
  • Moglibyśmy naprawić kod... (414)
  • ...ale trzeba naprawić funkcje systemu (415)
  • Określ, które funkcje działają (416)
  • TERAZ wiesz, co (nie) działa (419)
  • Co zrobiłbyś w tej sytuacji? (419)
  • Oszacuj czas pracy przy użyciu testów punktowych (420)
  • O czym informują Cię wyniki testów punktowych? (422)
  • Intuicja członków zespołu ma znaczenie (424)
  • Poinformuj klienta o szacunkowym czasie naprawy błędów (426)
  • Sytuacja wygląda dobrze... (430)
  • ...i kończysz iterację sukcesem! (431)
  • I klient jest zadowolony (432)
  • Narzędzia do Twojej programistycznej skrzynki narzędziowej (434)

Rozdział 12. Proces w praktyce

  • Definiowanie procesu rozwoju oprogramowania (436)
  • Dobry proces prowadzi do dobrego oprogramowania (437)
  • Wymagany jest strój wieczorowy (442)
  • Wybrane materiały dodatkowe (444)
  • Więcej wiedzy = lepszy proces (445)
  • Narzędzia do Twojej programistycznej skrzynki narzędziowej (446)

Dodatek A Pięć najważniejszych tematów (których nie poruszyliśmy)

  • Numer 1. Diagramy klas w notacji UML (450)
  • Numer 2. Diagramy sekwencji (452)
  • Numer 3. Opowieści użytkownika i przypadki użycia (454)
  • Numer 4. Testy systemu a testy jednostkowe (456)
  • Numer 5. Refaktoryzacja (457)

Dodatek B Narzędzia dla doświadczonych programistów

  • Techniki rozwoju (460)
  • Zasady rozwoju (462)

Skorowidz (465)

Dodaj do koszyka Head First Software Development. Edycja polska

Code, Publish & WebDesing by CATALIST.com.pl



(c) 2005-2024 CATALIST agencja interaktywna, znaki firmowe należą do wydawnictwa Helion S.A.