Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00340 005153 19015396 na godz. na dobę w sumie
Legendarny osobomiesiąc. Opowieści o inżynierii oprogramowania. Wydanie II - książka
Legendarny osobomiesiąc. Opowieści o inżynierii oprogramowania. Wydanie II - książka
Autor: Liczba stron: 336
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-5079-3 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> biznes it >> zarządzanie projektami it
Porównaj ceny (książka, ebook (-35%), audiobook).

Rocznicowe wydanie kultowej książki o zarządzaniu projektami w IT - to już 20 lat obecności na rynku i setki tysięcy sprzedanych egzemplarzy na świecie!

Zarządzanie procesem tworzenia oprogramowania bywa doświadczeniem bardzo pouczającym, a jednocześnie niezwykle frustrującym. Z jednej strony takie projekty są podobne do innych dużych przedsięwzięć, z drugiej - wymagają od kierownictwa sporo specjalistycznej wiedzy i specyficznego podejścia do zagadnień programistycznych. Oczywiście, wiedza na ten temat stale rośnie, pojawiają się też nowe koncepcje kierowania dużymi projektami. Jeśli brakuje Ci literatury, która potraktowałaby to zagadnienie kompleksowo, katalogowałaby poszczególne propozycje i opisywałaby je w przystępny i przydatny sposób - sięgnij po ten tytuł!

Książka Legendarny osobomiesiąc zyskała już miano kultowej; jest niezmiennie aktualna i wciąż inspiruje programistów na całym świecie. Składa się z kilkunastu esejów, które zawierają informacje i inspiracje bezcenne dla każdego menedżera i programisty. Przy dużych projektach konieczne jest zachowanie ich spójności koncepcyjnej, co w przypadku dużych zadań stanowi warunek dość trudny do spełnienia, dlatego wiele obiecujących przedsięwzięć zakończyło się porażką. Trzeba też zdawać sobie sprawę, że złożone zadanie oznacza dla zespołu dobre i złe chwile. Autor w niezwykle interesujący i praktyczny sposób pokazuje, jak czerpać siły z chwil radości i skutecznie radzić sobie z problemami, aby zakończyć z sukcesem nawet najbardziej złożony projekt programistyczny.

W tej książce znalazły się koncepcje obejmujące między innymi:

A także:

Nie ma drugiej tak wpływowej i ponadczasowej książki dla twórców oprogramowania!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) Tłumaczenie: Wojciech Moch ISBN: 978-83-283-5079-3 Authorized translation from the English language edition, entitled: THE MYTHICAL MAN-MONTHS, ANNIVERSARY EDITION, 2nd Edition; ISBN 0201835959; by Frederick Phillips Brooks; published by Pearson Education, Inc, publishing as Addison Wesley. Copyright © 1995 Addison Wesley Longman, Inc. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. Polish language edition published by HELION S.A. Copyright © 2019. The essay entitled, No Silver Bullet, is from Information Processing 1986, the Proceedings of the IFIP Tenth World Computing Conference, edited by H.-J. Kugler, 1986, pages 1069-1076. Reprinted with the kind permission of IFIP and Elsevier Science B.V., Amsterdam, The Netherlands. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Helion SA dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Helion SA nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Materiały graficzne na okładce zostały wykorzystane za zgodą Shutterstock Images LLC. Helion SA ul. Kościuszki 1c, 44-100 Gliwice tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/legoso Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis tre(cid:258)ci 7 Spis tre(cid:321)ci Wst(cid:218)p do wydania rocznicowego Wst(cid:218)p do pierwszego wydania 1. Smolisty dó(cid:239) 2. Legendarny osobomiesi(cid:200)c 3. Zespó(cid:239) chirurgiczny 4. Arystokracja, demokracja i projekt systemu 5. Efekt drugiego systemu 6. Przekazywanie wie(cid:258)ci 7. Dlaczego upad(cid:239)a wie(cid:285)a Babel? 8. Podejmowanie decyzji 9. Dziesi(cid:218)(cid:202) kilo w pi(cid:218)ciokilowym worku 10. Hipoteza dokumentacji 11. Plan odrzucania 12. Ostre narz(cid:218)dzia 11 15 21 31 47 59 71 79 91 105 115 125 133 145 Poleć książkęKup książkę 8 Legendarny osobomiesi(cid:200)c 13. Ca(cid:239)o(cid:258)(cid:202) i cz(cid:218)(cid:258)ci 14. Wysiadywanie katastrofy 15. Druga twarz 16. Nie ma srebrnej kuli — esencja i przypadek w in(cid:285)ynierii oprogramowania 17. Nie ma srebrnej kuli, raz jeszcze 18. Propozycje z „Legendarnego osobomiesi(cid:200)ca”: prawda czy fa(cid:239)sz? 19. Legendarny osobomiesi(cid:200)c — 20 lat pó(cid:283)niej Epilog. Pi(cid:218)(cid:202)dziesi(cid:200)t lat cudów, zachwytów i rado(cid:258)ci Przypisy ko(cid:241)cowe Skorowidz 159 173 183 199 227 251 277 315 317 333 Poleć książkęKup książkę Legendarny osobomiesi(cid:200)c 31 2. Legendarny osobomiesi(cid:167)c Dobra kuchnia wymaga czasu. Je(cid:352)eli zechcesz poczeka(cid:250), pozwoli to lepiej Ci(cid:170) obs(cid:174)u(cid:352)y(cid:250) i zadowoli(cid:250). MENU RESTAURACJI ANTOINE W NOWYM ORLEANIE Poleć książkęKup książkę 32 Legendarny osobomiesi(cid:200)c Wi(cid:171)cej projektów upad(cid:175)o z powodu braku czasu w kalendarzu ni(cid:352) z wszyst- kich innych powodów razem wzi(cid:171)tych. Dlaczego w(cid:175)a(cid:321)nie ten powód jest tak cz(cid:171)sty? Po pierwsze, nasze techniki szacowania s(cid:167) wyj(cid:167)tkowo s(cid:175)abej jako(cid:321)ci. Przede wszystkim, wyra(cid:352)aj(cid:167) one ciche (i niczym nieuzasadnione) za(cid:175)o(cid:352)e- nie, (cid:352)e wszystko uda si(cid:171) zrealizowa(cid:250) bez problemów. Po drugie, nasze techniki szacowania ch(cid:171)tnie mieszaj(cid:167) poj(cid:171)cia pracy i post(cid:171)pu, ukrywaj(cid:167)c w ten sposób nies(cid:175)uszne za(cid:175)o(cid:352)enie, (cid:352)e pracownik i mie- si(cid:167)c s(cid:167) poj(cid:171)ciami wymiennymi. Po trzecie, poniewa(cid:352) nie jeste(cid:321)my pewni poprawno(cid:321)ci naszych sza- cunków, kadrze zarz(cid:167)dzaj(cid:167)cej cz(cid:171)sto brakuje tego wspania(cid:175)ego uporu szefa restauracji Antoine. Po czwarte, post(cid:171)py projektu s(cid:167) zazwyczaj s(cid:175)abo monitorowane. Tech- niki, które dobrze si(cid:171) sprawdzi(cid:175)y w innych dziedzinach in(cid:352)ynierskich i dla- tego s(cid:167) w nich stosowane rutynowo, w przypadku in(cid:352)ynierii oprogramo- wania uznawane s(cid:167) za radykalne innowacje. Po pi(cid:167)te, w przypadku zauwa(cid:352)enia opó(cid:350)nie(cid:302) w harmonogramie ca(cid:175)- kowicie naturaln(cid:167) (i tradycyjn(cid:167)) reakcj(cid:167) jest dodanie do zespo(cid:175)u nowych programistów. Powoduje to tylko ci(cid:167)g(cid:175)e pogarszanie si(cid:171) sytuacji i przy- pomina próby gaszenia ognia benzyn(cid:167). Wi(cid:171)kszy ogie(cid:302) wymaga u(cid:352)ycia wi(cid:171)k- szej ilo(cid:321)ci benzyny, a powtarzaj(cid:167)cy si(cid:171) w ten sposób cykl prowadzi prosto do katastrofy. Monitorowanie post(cid:171)pów b(cid:171)dzie tematem jednego z rozdzia(cid:175)ów, teraz przyjrzyjmy si(cid:171) innym aspektom tego problemu. OPTYMIZM Wszyscy programi(cid:321)ci s(cid:167) optymistami. By(cid:250) mo(cid:352)e nowoczesna forma magii przyci(cid:167)ga do siebie osoby, które wierz(cid:167) w szcz(cid:171)(cid:321)liwe zako(cid:302)czenia i Wró(cid:352)ki Z(cid:171)buszki. By(cid:250) mo(cid:352)e setki powodów do frustracji odstrasza wszystkich tych, którzy ca(cid:175)kowicie koncentruj(cid:167) si(cid:171) na osi(cid:167)gni(cid:171)ciu celu. By(cid:250) mo(cid:352)e wynika to z tego, (cid:352)e komputery s(cid:167) jeszcze ca(cid:175)kiem m(cid:175)ode, programi(cid:321)ci s(cid:167) jeszcze m(cid:175)odsi, a m(cid:175)odzie(cid:352) zawsze promienieje optymizmem. Niezale(cid:352)nie od tego, jak dzia(cid:175)a ten mechanizm selekcji, w jego wyniku pojawiaj(cid:167) si(cid:171) takie stwier- dzenia jak: „Tym razem na pewno zadzia(cid:175)a” albo „W(cid:175)a(cid:321)nie znalaz(cid:175)em ostatni b(cid:175)(cid:167)d”. Poleć książkęKup książkę Legendarny osobomiesi(cid:200)c 33 A zatem pierwsze fa(cid:175)szywe za(cid:175)o(cid:352)enie stanowi(cid:167)ce podstaw(cid:171) harmono- gramów tworzonych systemów programistycznych brzmi: Wszystko pójdzie jak nale(cid:352)y, czyli ka(cid:352)de zadanie zajmie tylko tyle czasu ile „powinno” zaj(cid:167)(cid:250). Taka powszechno(cid:321)(cid:250) optymizmu w(cid:321)ród programistów zas(cid:175)uguje na co(cid:321) wi(cid:171)cej ni(cid:352) tylko pobie(cid:352)n(cid:167) analiz(cid:171). Dorothy Sayers w swojej doskona(cid:175)ej ksi(cid:167)(cid:352)ce The Mind of the Maker dzieli dzia(cid:175)ania kreatywne na trzy etapy: pomys(cid:175)u, implementacji i interakcji. Oznacza to, (cid:352)e ksi(cid:167)(cid:352)ka, komputer lub program powstaje najpierw jako konstrukcja idealna, stworzona po- za czasem i przestrzeni(cid:167), ale w umy(cid:321)le jej autora kompletna i doskona(cid:175)a. Nast(cid:171)pnie jest realizowana w czasie i przestrzeni za pomoc(cid:167) pióra, atra- mentu i papieru albo przewodów, krzemu i (cid:352)elaza. Taka kreacja zostaje uko(cid:302)czona, gdy kto(cid:321) przeczyta ksi(cid:167)(cid:352)k(cid:171), skorzysta z komputera albo uru- chomi program, wchodz(cid:167)c tym samym w interakcj(cid:171) z umys(cid:175)em twórcy. Taki opis, którego Sayers u(cid:352)ywa nie tylko do obja(cid:321)nienia ludzkiej kreatywno(cid:321)ci, ale te(cid:352) chrze(cid:321)cija(cid:302)skiej doktryny Trójcy (cid:320)wi(cid:171)tej, przyda si(cid:171) w naszym aktualnym zadaniu. W przypadku ludzkich twórców ró(cid:352)nych rzeczy niedoskona(cid:175)o(cid:321)ci i niespójno(cid:321)ci naszych idei staj(cid:167) si(cid:171) widoczne pod- czas ich implementowania. Oznacza to, (cid:352)e pisanie, eksperymentowanie, „(cid:250)wiczenie” s(cid:167) bardzo wa(cid:352)nymi elementami dla teoretyka. W wielu dzia(cid:175)aniach kreatywnych medium ich realizacji jest trudne do opanowania. Drewno si(cid:171) (cid:175)amie, farby brudz(cid:167), a uk(cid:175)ady elektryczne si(cid:171) przepalaj(cid:167). Takie fizyczne ograniczenia stosowanego medium sprawiaj(cid:167), (cid:352)e nie wszystkie idee mo(cid:352)na za ich pomoc(cid:167) wyrazi(cid:250), a na dodatek tworz(cid:167) nieoczekiwane problemy podczas implementowania. Sama implementacja te(cid:352) wymaga czasu i pracy, co wynika zarówno z wykorzystania fizycznego medium, jak i z niedopasowania samych idei. Zazwyczaj win(cid:171) za wi(cid:171)kszo(cid:321)(cid:250) problemów z implementacj(cid:167) zrzucamy na fizyczne medium. Po prostu medium nie jest „nasze” w ten sposób, w jaki „nasze” s(cid:167) idee, a duma zawsze wp(cid:175)ywa na nasze oceny. Programowanie komputerów to jednak praca z niezwykle plastycznym medium. Programi(cid:321)ci tworz(cid:167) wy(cid:175)(cid:167)cznie za pomoc(cid:167) w(cid:175)asnych my(cid:321)li, stosuj(cid:167)c same idee oraz ich niezwykle elastyczne reprezentacje. Z powodu tak wielkiej plastyczno(cid:321)ci u(cid:352)ywanego medium oczekujemy niemal(cid:352)e ca(cid:175)kowi- tego braku k(cid:175)opotów przy implementowaniu. To w(cid:175)a(cid:321)nie z tego wynika nasz nieod(cid:175)(cid:167)czny optymizm. Niestety nasze idee nie s(cid:167) idealne, a zatem powstaj(cid:167) b(cid:175)(cid:171)dy podczas implementowania. To z kolei oznacza, (cid:352)e nasz optymizm jest nieuzasadniony. Poleć książkęKup książkę 34 Legendarny osobomiesi(cid:200)c W przypadku pojedynczego zadania za(cid:175)o(cid:352)enie, (cid:352)e uda si(cid:171) je zrealizo- wa(cid:250) bez problemów, ma probabilistyczny wp(cid:175)yw na ca(cid:175)y harmonogram. Rzeczywi(cid:321)cie wszystko mo(cid:352)e pój(cid:321)(cid:250) zgodnie z planem, poniewa(cid:352) prawdo- podobie(cid:302)stwo opó(cid:350)nienia w danym zadaniu ma pewien rozk(cid:175)ad, w którym mo(cid:352)na wyznaczy(cid:250) prawdopodobie(cid:302)stwo wyst(cid:167)pienia „braku opó(cid:350)nie- nia”. Niestety du(cid:352)e projekty programistyczne sk(cid:175)adaj(cid:167) si(cid:171) z wielkiej licz- by zada(cid:302), z których cz(cid:171)(cid:321)(cid:250) musi by(cid:250) wykonywana sekwencyjnie. W takich warunkach prawdopodobie(cid:302)stwo, (cid:352)e (cid:352)adne z nich nie b(cid:171)dzie mia(cid:175)o opó(cid:350)- nie(cid:302), jest bardzo niskie. OSOBOMIESI(cid:107)C Kolejnym gro(cid:350)nym sposobem my(cid:321)lenia jest stosowanie samej jednostki wykonywanej pracy podczas szacowania oraz przygotowywania harmo- nogramu: osobomiesi(cid:167)ca. Rzeczywi(cid:321)cie koszt tworzenia oprogramowania mo(cid:352)na wyrazi(cid:250) jako iloczyn liczby pracowników i liczby przepracowanych miesi(cid:171)cy. Nie dotyczy to jednak post(cid:171)pów. Oznacza to, (cid:352)e osobomiesi(cid:167)c sto- sowany jako jednostka miary wielko(cid:321)ci poszczególnych zada(cid:302) jest bardzo niebez- piecznym i podst(cid:170)pnym mitem. Sugeruje, (cid:352)e pracownicy i miesi(cid:167)ce s(cid:167) warto- (cid:321)ciami wymiennymi. Pracownicy i miesi(cid:167)ce staj(cid:167) si(cid:171) warto(cid:321)ciami wymiennymi jedynie, gdy dane zadanie mo(cid:352)na podzieli(cid:250) pomi(cid:171)dzy wielu pracowników, nie wyma- gaj(cid:167)c od nich (cid:352)adnej komunikacji (rysunek 2.1). Takie podej(cid:321)cie sprawdza si(cid:171) przy m(cid:175)óceniu pszenicy lub zbieraniu bawe(cid:175)ny, ale w przypadku pro- gramowania systemów zupe(cid:175)nie nie ma zastosowania. Rysunek 2.1. Czas a liczba pracowników — zadanie doskonale podzielne Poleć książkęKup książkę Legendarny osobomiesi(cid:200)c 35 Je(cid:352)eli zadania nie da si(cid:171) podzieli(cid:250), na przyk(cid:175)ad z powodu ogranicze(cid:302) wynikaj(cid:167)cych z sekwencji prac, to przypisanie do niego dodatkowych pra- cowników nie b(cid:171)dzie mia(cid:175)o wp(cid:175)ywu na harmonogram (rysunek 2.2). Uro- dzenie dziecka zajmuje zawsze dziewi(cid:171)(cid:250) miesi(cid:171)cy, niezale(cid:352)nie od tego, ile kobiet zostanie przydzielonych do tego zadania. Wiele zada(cid:302) programi- stycznych ma taki w(cid:175)a(cid:321)nie charakter, co wynika z sekwencyjnej natury debugowania. Rysunek 2.2. Czas a liczba pracowników — zadanie niepodzielne W przypadku zada(cid:302), które mo(cid:352)na podzieli(cid:250), ale wymagaj(cid:167) one komu- nikacji pomi(cid:171)dzy poszczególnymi zadaniami cz(cid:167)stkowymi, do ilo(cid:321)ci pracy koniecznej do wykonania trzeba doliczy(cid:250) jeszcze prac(cid:171) zwi(cid:167)zan(cid:167) z sam(cid:167) komunikacj(cid:167). Oznacza to, (cid:352)e najlepszy efekt, jaki mo(cid:352)na uzyska(cid:250), b(cid:171)dzie zawsze gorszy od prostej zamiany pracowników na miesi(cid:167)ce (rysunek 2.3). Dodatkowe obci(cid:167)(cid:352)enia zwi(cid:167)zane z komunikacj(cid:167) mo(cid:352)na podzieli(cid:250) na dwie kategorie: nauk(cid:171) oraz wymian(cid:171) informacji. Ka(cid:352)dy z pracowników musi nauczy(cid:250) si(cid:171) korzysta(cid:250) ze stosowanej technologii, pozna(cid:250) cele ca(cid:175)ego przedsi(cid:171)wzi(cid:171)cia, ogóln(cid:167) strategi(cid:171) oraz plan pracy. Takiej nauki nie da si(cid:171) podzieli(cid:250) na mniejsze cz(cid:171)(cid:321)ci, a zatem ta kategoria obci(cid:167)(cid:352)enia powoduje wzrost nak(cid:175)adu pracy rosn(cid:167)cy liniowo wraz ze wzrostem liczby pracow- nikówI. Poleć książkęKup książkę 36 Legendarny osobomiesi(cid:200)c Rysunek 2.3. Czas a liczba pracowników — podzielne zadanie wymagaj(cid:167)ce komunikacji Druga kategoria, czyli wymiana informacji, jest znacznie gorsza. Je(cid:352)eli ka(cid:352)da cz(cid:171)(cid:321)(cid:250) zadania musi by(cid:250) koordynowana z pozosta(cid:175)ymi cz(cid:171)(cid:321)ciami, to wymagany nak(cid:175)ad pracy ro(cid:321)nie zgodnie ze wzorem: n(n –1)/2. Trzech pracowników wymaga trzykrotnie intensywniejszej komunikacji dwu- stronnej ni(cid:352) dwóch. Czterech wymaga ju(cid:352) sze(cid:321)ciokrotnie wi(cid:171)cej komu- nikacji dwustronnej. Co wi(cid:171)cej, je(cid:352)eli konieczne s(cid:167) konferencje mi(cid:171)dzy trzema, czterema lub wi(cid:171)ksz(cid:167) liczb(cid:167) pracowników w celu wspólnego roz- wi(cid:167)zywania problemów, to sprawy komplikuj(cid:167) si(cid:171) jeszcze bardziej. Do- datkowe nak(cid:175)ady zwi(cid:167)zane z komunikacj(cid:167) mog(cid:167) ca(cid:175)kowicie zanegowa(cid:250) zyski wynikaj(cid:167)ce z podzia(cid:175)u zadania, przez co znajdziemy si(cid:171) w sytuacji przedstawionej na rysunku 2.4. Tworzenie systemów programowych to jednoznacznie zadanie sys- temowe i jako takie wymaga obs(cid:175)u(cid:352)enia wielu powi(cid:167)za(cid:302). Oznacza to, (cid:352)e nak(cid:175)ady na komunikacj(cid:171) s(cid:167) bardzo wysokie i potrafi(cid:167) szybko zdominowa(cid:250) czas wykonania poszczególnych zada(cid:302), nawet po ich podzieleniu. W takiej sytuacji dodanie nowych pracowników zamiast skraca(cid:250), b(cid:171)dzie wyd(cid:175)u(cid:352)a(cid:250) harmonogram prac. Poleć książkęKup książkę Legendarny osobomiesi(cid:200)c 37 Rysunek 2.4. Czas a liczba pracowników — zadanie ze z(cid:174)o(cid:352)onymi zale(cid:352)no(cid:321)ciami wzajemnymi TESTY SYSTEMOWE Debugowanie komponentów i testy systemowe to cz(cid:171)(cid:321)ci harmonogramu, które s(cid:167) najbardziej ograniczane przez konieczno(cid:321)(cid:250) utrzymania sekwencji prac. Co wi(cid:171)cej, czas wymagany do ich wykonania uzale(cid:352)niony jest od liczby i skomplikowania wykrytych b(cid:175)(cid:171)dów. Teoretycznie takich b(cid:175)(cid:171)dów nie powinno by(cid:250) wcale. Z powodu naszego optymizmu zazwyczaj ocze- kujemy, (cid:352)e ogólnie b(cid:175)(cid:171)dów b(cid:171)dzie mniej, ni(cid:352) jest ich w rzeczywisto(cid:321)ci. W zwi(cid:167)zku z tym testowanie jest najgorzej zaplanowanym etapem tworze- nia oprogramowania. Przez wiele lat, z sukcesem, stosowa(cid:175)em poni(cid:352)sz(cid:167) ogóln(cid:167) regu(cid:175)(cid:171) plano- wania harmonogramu prac dla zadania programowego: 1/3 to planowanie 1/6 to tworzenie kodu 1/4 to testy komponentów i wczesne testy systemowe 1/4 to testy systemowe, gdy gotowe s(cid:167) ju(cid:352) wszystkie komponenty W kilku punktach ró(cid:352)ni si(cid:171) to od konwencjonalnego przygotowywania harmonogramu: (cid:120) Cz(cid:171)(cid:321)(cid:250) przeznaczona na planowanie jest wi(cid:171)ksza ni(cid:352) normalnie stosowana. Mimo to i tak czasu z ledwo(cid:321)ci(cid:167) wystarcza na przygotowanie szczegó(cid:175)owej i porz(cid:167)dnej specyfikacji. Poleć książkęKup książkę 38 Legendarny osobomiesi(cid:200)c Jest te(cid:352) ca(cid:175)kowicie niewystarczaj(cid:167)ca, je(cid:352)eli chcieliby(cid:321)my przeprowadzi(cid:250) badania i (cid:250)wiczenia w nowych technikach. (cid:120) Po(cid:174)owa harmonogramu jest zwi(cid:167)zana z debugowaniem gotowego kodu i jest to warto(cid:321)(cid:250) zdecydowanie wi(cid:171)ksza ni(cid:352) normalnie stosowana. (cid:120) Cz(cid:171)(cid:321)(cid:250), która jest naj(cid:175)atwiejsza do oszacowania, czyli tworzenie kodu, otrzyma(cid:175)a zaledwie jedn(cid:167) szóst(cid:167) ca(cid:175)o(cid:321)ci czasu. Kontroluj(cid:167)c konwencjonalnie planowane projekty, zauwa(cid:352)y(cid:175)em, (cid:352)e zaledwie kilka z nich przeznacza(cid:175)o po(cid:175)ow(cid:171) harmonogramu na testowanie, ale niemal we wszystkich, w rzeczywisto(cid:321)ci, po(cid:175)ow(cid:171) czasu zajmowa(cid:175)o te- stowanie. W wielu z tych projektów prace post(cid:171)powa(cid:175)y zgodnie z harmo- nogramem do momentu rozpocz(cid:171)cia testów systemowychII. B(cid:175)(cid:167)d polegaj(cid:167)cy na nieprzydzieleniu odpowiedniej ilo(cid:321)ci czasu na testy, w szczególno(cid:321)ci na testy systemowe, ma katastrofalne skutki. Poniewa(cid:352) takie opó(cid:350)nienie pojawia si(cid:171) pod koniec ca(cid:175)ego harmonogramu, niemal do samego ko(cid:302)ca nikt nie ma poj(cid:171)cia, (cid:352)e projekt ma jakiekolwiek k(cid:175)opoty. Z(cid:175)e wie(cid:321)ci przekazywane tak pó(cid:350)no i bez ostrze(cid:352)enia s(cid:167) niezwykle depry- muj(cid:167)ce zarówno dla klientów, jak i dla kadry zarz(cid:167)dzaj(cid:167)cej. Co wi(cid:171)cej, opó(cid:350)nienia pojawiaj(cid:167)ce si(cid:171) na tym etapie zazwyczaj maj(cid:167) powa(cid:352)ne reperkusje zarówno finansowe, jak i psychologiczne. Projekt ma pe(cid:175)n(cid:167) obsad(cid:171), a zatem koszt ka(cid:352)dego dnia prac jest maksymalny. Co wa(cid:352)- niejsze, tworzone oprogramowanie powinno stanowi(cid:250) wsparcie dla in- nych dzia(cid:175)ów firmy (dostawy komputerów, prace w nowych oddzia(cid:175)ach i inne) i takie pochodne koszty opó(cid:350)nienia mog(cid:167) by(cid:250) bardzo wysokie, po- niewa(cid:352) inni spodziewaj(cid:167) si(cid:171) teraz otrzyma(cid:250) gotowe oprogramowanie. I rzeczywi(cid:321)cie, takie pochodne koszty opó(cid:350)nienia mog(cid:167) szybko prze- wy(cid:352)szy(cid:250) wszystkie pozosta(cid:175)e. Z tego powodu bardzo wa(cid:352)ne jest, (cid:352)eby w pierwotnym harmonogramie przeznaczy(cid:250) odpowiednio du(cid:352)o czasu na testy systemowe. SZACOWANIE TCHÓRZLIWE Zauwa(cid:352), (cid:352)e w przypadku programisty, jak w przypadku kucharza, naciski ze strony prze(cid:175)o(cid:352)onego mog(cid:167) wp(cid:175)ywa(cid:250) na planowany czas wykonania za- dania, ale nie b(cid:171)d(cid:167) mia(cid:175)y wp(cid:175)ywu na czas faktycznego uko(cid:302)czenia. Przygo- towywanie omletu, który zgodnie z planem ma by(cid:250) gotowy w dwie minuty, Poleć książkęKup książkę Legendarny osobomiesi(cid:200)c 39 mo(cid:352)e post(cid:171)powa(cid:250) zgodnie z harmonogramem. Je(cid:352)eli jednak po dwóch minutach nie b(cid:171)dzie gotowy, to klient ma dwie mo(cid:352)liwo(cid:321)ci: albo pocze- ka(cid:250), albo zje(cid:321)(cid:250) surowe jajka. Klienci czekaj(cid:167)cy na swoje oprogramowanie maj(cid:167) podobny wybór. Kucharz mo(cid:352)e jeszcze podnie(cid:321)(cid:250) temperatur(cid:171). W efekcie zazwyczaj po- wstaje omlet ca(cid:175)kowicie niejadalny — przypalony z do(cid:175)u, a surowy z góry. Nie s(cid:167)dz(cid:171), by mened(cid:352)erowie oprogramowania mieli mniej odwagi i niez(cid:175)omno(cid:321)ci od kucharzy, podobnie jak inni mened(cid:352)erowie prowa- dz(cid:167)cy projekty in(cid:352)ynierskie. Niestety (cid:350)le przygotowane harmonogramy, które dopasowywane s(cid:167) do daty wyznaczonej przez zleceniodawc(cid:171), w na- szej bran(cid:352)y pojawiaj(cid:167) si(cid:171) znacznie cz(cid:171)(cid:321)ciej ni(cid:352) w innych dzia(cid:175)ach in(cid:352)ynier- skich. Niezwykle trudno jest przygotowa(cid:250) powa(cid:352)n(cid:167) obron(cid:171) swojego planu, ryzykuj(cid:167)c przy tym utrat(cid:171) pracy, szczególnie gdy taki plan nie zosta(cid:175) zbu- dowany z wykorzystaniem (cid:352)adnej solidnej metody, do dyspozycji mieli- (cid:321)my tylko niewiele danych, a poparty jest jedynie ogólnymi odczuciami mened(cid:352)erów. Oczywi(cid:321)cie potrzeba nam tutaj dwóch rozwi(cid:167)za(cid:302). Musimy przygo- towa(cid:250) i opublikowa(cid:250) wska(cid:350)niki produktywno(cid:321)ci, wska(cid:350)niki wykrywalno(cid:321)ci b(cid:175)(cid:171)dów, regu(cid:175)y szacowania i tym podobne. Ca(cid:175)a nasza bran(cid:352)a mo(cid:352)e tylko zyska(cid:250), je(cid:352)eli takie informacje stan(cid:167) si(cid:171) publicznie dost(cid:171)pne. Do czasu, a(cid:352) szacowanie b(cid:171)dzie mog(cid:175)o by(cid:250) realizowane na tak solid- nej podstawie, mened(cid:352)erowie musz(cid:167) usztywni(cid:250) swoje karki i broni(cid:250) przy- gotowanych przez siebie szacunków, maj(cid:167)c pewno(cid:321)(cid:250), (cid:352)e ich niepoparte niczym odczucia i tak s(cid:167) znacznie lepsze od szacowania (cid:352)yczeniowego. POWTARZALNE KATASTROFY HARMONOGRAMÓW Co nale(cid:352)y zrobi(cid:250), je(cid:352)eli w wa(cid:352)nym projekcie programistycznym nie da si(cid:171) dotrzyma(cid:250) harmonogramu? Oczywi(cid:321)cie zatrudni(cid:250) wi(cid:171)cej ludzi! Jak wida(cid:250) na rysunkach od 2.1 do 2.4, takie podst(cid:171)powanie nie zawsze jest prawdziw(cid:167) pomoc(cid:167). Przyjrzyjmy si(cid:171) pewnemu przyk(cid:175)adowiIII. Za(cid:175)ó(cid:352)my, (cid:352)e do zadania sza- cowanego na dwana(cid:321)cie osobomiesi(cid:171)cy przydzielono trzech pracowników na cztery miesi(cid:167)ce. Zdefiniowano te(cid:352) cztery mierzalne kamienie milowe oznaczone A, B, C i D, które zosta(cid:175)y zaplanowane na koniec ka(cid:352)dego miesi(cid:167)ca (rysunek 2.5). Poleć książkęKup książkę 40 Legendarny osobomiesi(cid:200)c Rysunek 2.5. Za(cid:175)ó(cid:352)my teraz, (cid:352)e pierwszy z kamieni milowych uda(cid:175)o si(cid:171) osi(cid:167)gn(cid:167)(cid:250) dopiero po up(cid:175)ywie dwóch miesi(cid:171)cy (rysunek 2.6). Jakie decyzje mo(cid:352)e podj(cid:167)(cid:250) w takiej sytuacji mened(cid:352)er? 1. Za(cid:175)o(cid:352)y(cid:250), (cid:352)e zadanie musi zosta(cid:250) wykonane w zaplanowanym czasie. Zak(cid:175)ada si(cid:171) zatem, (cid:352)e tylko pierwsza cz(cid:171)(cid:321)(cid:250) ca(cid:175)ego zadania zosta(cid:175)a (cid:350)le oszacowana, czyli rysunek 2.6 ca(cid:175)kiem dobrze przedstawia ak- tualn(cid:167) sytuacj(cid:171). Wówczas pozostaje jeszcze dziewi(cid:171)(cid:250) osobomiesi(cid:171)cy prac i tylko dwa miesi(cid:167)ce na ich wykonanie, czyli po cztery i pó(cid:175) osoby na ka(cid:352)dy z miesi(cid:171)cy. Oznacza to, (cid:352)e do trzyosobowego ze- spo(cid:175)u trzeba doda(cid:250) jeszcze dwóch pracowników. Rysunek 2.6. Poleć książkęKup książkę Legendarny osobomiesi(cid:200)c 41 2. Za(cid:175)o(cid:352)y(cid:250), (cid:352)e zadanie musi zosta(cid:250) wykonane w zaplanowanym czasie. Zak(cid:175)ada si(cid:171) te(cid:352), (cid:352)e ca(cid:175)o(cid:321)(cid:250) planu zosta(cid:175)a oszacowana za nisko, a zatem aktualn(cid:167) sytuacj(cid:171) lepiej opisuje rysunek 2.7. W tej sytuacji pozo- staje do wykonania jeszcze osiemna(cid:321)cie osobomiesi(cid:171)cy prac, czyli potrzeba nam dziewi(cid:171)ciu pracowników. Oznacza to, (cid:352)e do trzy- osobowego zespo(cid:175)u trzeba doda(cid:250) jeszcze sze(cid:321)ciu pracowników. Rysunek 2.7. 3. Zmieni(cid:250) ca(cid:175)y harmonogram. Bardzo podoba mi si(cid:171) rada P. Fagga — do(cid:321)wiadczonego in(cid:352)yniera, który mówi(cid:175): „Nie akceptuj ma(cid:175)ych po(cid:321)lizgów”. Oznacza to, (cid:352)e w nowym harmonogramie trzeba za- planowa(cid:250) do(cid:321)(cid:250) czasu, aby mie(cid:250) pewno(cid:321)(cid:250), (cid:352)e prace zostan(cid:167) przepro- wadzone rzetelnie i dok(cid:175)adnie, tak (cid:352)eby nie trzeba by(cid:175)o dokonywa(cid:250) kolejnych korekt. 4. Zmniejszy(cid:250) wielko(cid:321)(cid:250) zadania. W praktyce zadania i tak s(cid:167) reduko- wane, gdy tylko zauwa(cid:352)one zostan(cid:167) opó(cid:350)nienia. Je(cid:352)eli pochodne koszty opó(cid:350)nie(cid:302) s(cid:167) bardzo wysokie, to jest to jedyne akceptowalne rozwi(cid:167)zanie. Mened(cid:352)er ma zatem do wyboru formalne zmniejszenie zadania, korekt(cid:171) harmonogramu albo ciche obserwowanie, jak za- danie zostaje ograniczone przez pospieszne projektowanie i niepe(cid:175)- ne testy. W pierwszych dwóch przypadkach upieranie si(cid:171), (cid:352)e niezmienione za- danie mo(cid:352)e zosta(cid:250) zrealizowane w cztery miesi(cid:167)ce, to prosta droga do kata- strofy. Przyjrzyjmy si(cid:171) efektom regeneracyjnym, na przyk(cid:175)ad dla pierwszego Poleć książkęKup książkę 42 Legendarny osobomiesi(cid:200)c rozwi(cid:167)zania (rysunek 2.8). Dwóch nowych pracowników, niezale(cid:352)nie od tego, jak b(cid:171)d(cid:167) kompetentni i jak szybko zostan(cid:167) pozyskani dla projektu, b(cid:171)dzie wymaga(cid:175)o wdro(cid:352)enia w tematyk(cid:171) zadania przez jednego z do(cid:321)wiad- czonych programistów. Je(cid:352)eli zajmie to jeden miesi(cid:167)c, to znaczy, (cid:352)e trzy osobomiesi(cid:167)ce zostan(cid:167) zu(cid:352)yte na prace niezwi(cid:167)zane z pierwotnym harmono- gramem. Co wi(cid:171)cej, zadanie, które pocz(cid:167)tkowo podzielono na trzy cz(cid:171)(cid:321)ci, teraz musi zosta(cid:250) podzielone na pi(cid:171)(cid:250). A to oznacza, (cid:352)e cz(cid:171)(cid:321)(cid:250) wykonanych ju(cid:352) prac zostanie stracona, natomiast wyd(cid:175)u(cid:352)ona musi zosta(cid:250) faza testów systemowych. A zatem pod koniec trzeciego miesi(cid:167)ca do przepracowa- nia zostanie jeszcze siedem osobomiesi(cid:171)cy, podczas gdy dost(cid:171)pnych b(cid:171)- dziemy mieli jeden miesi(cid:167)c i pi(cid:171)ciu przeszkolonych pracowników. Z ry- sunku 2.8 wynika, (cid:352)e projekt b(cid:171)dzie mia(cid:175) takie samo opó(cid:350)nienie, jakie mia(cid:175)by bez dodawania do zespo(cid:175)u dodatkowych pracowników (rysunek 2.6). Rysunek 2.8. Aby mie(cid:250) nadziej(cid:171) na zako(cid:302)czenie prac w cztery miesi(cid:167)ce, bior(cid:167)c pod uwag(cid:171) sam czas szkolenia i nie uwzgl(cid:171)dniaj(cid:167)c konieczno(cid:321)ci ponownego podzia(cid:175)u zada(cid:302) oraz dodatkowych testów systemowych, pod koniec dru- giego miesi(cid:167)ca powinni(cid:321)my doda(cid:250) do zespo(cid:175)u czterech, a nie dwóch pra- cowników. Chc(cid:167)c te(cid:352) pokry(cid:250) nak(cid:175)ady zwi(cid:167)zane z ponownym podzia(cid:175)em i dodatkowymi testami, nale(cid:352)a(cid:175)oby rozwa(cid:352)y(cid:250) dodanie do zespo(cid:175)u kolejnych osób. W takiej sytuacji powstanie jednak zespó(cid:175) sk(cid:175)adaj(cid:167)cy si(cid:171) przynajm- niej z siedmiu osób, a nie tylko z trzech. W zwi(cid:167)zku z tym organizacja zespo(cid:175)u oraz podzia(cid:175) zada(cid:302) stanowi(cid:167) zupe(cid:175)nie inny rodzaj problemu. Poleć książkęKup książkę Legendarny osobomiesi(cid:200)c 43 Prosz(cid:171) zauwa(cid:352)y(cid:250), (cid:352)e pod koniec trzeciego miesi(cid:167)ca sprawy wygl(cid:167)daj(cid:167) bardzo (cid:350)le. Pierwszy etap prac nie zosta(cid:175) uko(cid:302)czony mimo wzmo(cid:352)onych wysi(cid:175)ków mened(cid:352)erskich. Bardzo mocna jest pokusa powtórzenia ca(cid:175)ego cyklu przez dodanie do zespo(cid:175)u kolejnych pracowników. To czyste sza- le(cid:302)stwo. To wszystko jest prawd(cid:167) przy za(cid:175)o(cid:352)eniu, (cid:352)e tylko pierwszy etap prac zosta(cid:175) (cid:350)le zaplanowany. Je(cid:352)eli po jego uko(cid:302)czeniu przyjmiemy rozs(cid:167)dne za(cid:175)o(cid:352)enie, (cid:352)e ca(cid:175)o(cid:321)(cid:250) harmonogramu by(cid:175)a zbyt optymistyczna, tak jak na rysunku 2.7, to potrzebnych b(cid:171)dzie sze(cid:321)ciu dodatkowych pracowników tylko po to, aby zrealizowa(cid:250) pierwotne zadanie. Obliczenie czasu po- trzebnego na szkolenie, ponowny podzia(cid:175) prac i testy systemowe pozo- stawiam jako (cid:250)wiczenie dla czytelnika. Bez w(cid:167)tpienia taka samonap(cid:171)dzaj(cid:167)- ca si(cid:171) katastrofa nie pozostanie bez wp(cid:175)ywu na jako(cid:321)(cid:250) produktu, który zostanie dostarczony pó(cid:350)niej, ni(cid:352) to by nast(cid:167)pi(cid:175)o w przypadku korekty harmonogramu i pozostaniu przy pierwotnym, trzyosobowym zespole. Nadmiernie upraszczaj(cid:167)c, mo(cid:352)emy tu zdefiniowa(cid:250) prawo Brooka: Dodawanie pracowników do opó(cid:350)nionego projektu tylko zwi(cid:170)ksza opó(cid:350)nienie. W ten sposób chc(cid:171) zdemitologizowa(cid:250) osobomiesi(cid:167)c. Liczba miesi(cid:171)cy trwania projektu zale(cid:352)y od wielu ogranicze(cid:302) sekwencyjnych. Maksymal- na liczba pracowników uzale(cid:352)niona jest od liczby niezale(cid:352)nych od siebie zada(cid:302) podrz(cid:171)dnych. Na podstawie tych dwóch wska(cid:350)ników mo(cid:352)na przy- gotowa(cid:250) harmonogram wymagaj(cid:167)cy mniejszej liczby pracowników, ale wi(cid:171)kszej liczby miesi(cid:171)cy. (Jedynym ryzykiem jest przedawnienie si(cid:171) pro- duktu). Nie da si(cid:171) jednak uzyska(cid:250) realizowalnego harmonogramu wyma- gaj(cid:167)cego wi(cid:171)kszej liczby osób, a mniejszej liczby miesi(cid:171)cy. Wi(cid:171)cej projek- tów programistycznych leg(cid:175)o w gruzach z powodu braku czasu ni(cid:352) z powodu wszystkich innych przyczyn razem wzi(cid:171)tych. Poleć książkęKup książkę 44 Legendarny osobomiesi(cid:200)c I II III V.A. Vyssotsky z laboratoriów Bell Telephone ocenia, (cid:298)e wielki projekt mo(cid:298)e przetrwa(cid:252) wzrost zatrudnienia do wielko(cid:286)ci 30 procent rocznie. Szybsze przyrosty utrudniaj(cid:261), a nawet uniemo(cid:298)liwiaj(cid:261) ewolucj(cid:266) najwa(cid:298)niejszych nieformalnych struktur oraz istniej(cid:261)cych (cid:286)cie(cid:298)ek komunikacji, o których b(cid:266)dzie mowa w rozdziale 7. F.J. Corbat z MIT wskazuje, (cid:298)e wielki projekt musi liczy(cid:252) si(cid:266) z wymian(cid:261) kadr na poziomie 20 procent rocznie, a nowi pracownicy musz(cid:261) zosta(cid:252) przeszkoleni i w(cid:225)(cid:261)czeni w formalne struktury organizacji. C. Portman z firmy International Computers Limited mówi: „Gdy wszystko ju(cid:298) dzia(cid:225)a jak nale(cid:298)y i zosta(cid:225)o odpowiednio zintegrowane, to masz przed sob(cid:261) jeszcze cztery miesi(cid:261)ce pracy”. Kilka innych sposobów podzia(cid:225)u harmonogramu podawanych jest w: R.W. Wolverton, The Cost of Developing Large-Scale Software, „IEEE Trans, on Computers”, C-23, 6 (czerwiec 1974), str. 615 – 636. Rysunki od 2.5 do 2.8 s(cid:261) dzie(cid:225)em Jerry’ego Ogdina, który cytuj(cid:261)c moje przyk(cid:225)ady z jednej z wcze(cid:286)niejszych publikacji tego rozdzia(cid:225)u, znacznie poprawi(cid:225) wcze(cid:286)niejsze ilustracje. J.L. Ogdin, The Mongolian Hordes versus Superprogrammer, „Infosystems” (grudzie(cid:276) 1972), str. 20 – 23. Poleć książkęKup książkę Skorowidz 333 Skorowidz A administrator, 51 aktualizacje, 168 architekt, 72, 256, 280 Aron Joel, 108 audyt projektu, 92 B bezpo(cid:321)rednie do(cid:175)(cid:167)czenie, 84 biblioteka, 262 g(cid:175)ówna, 267 programowa, 150 b(cid:175)(cid:171)dy, 160 szacowania, 108 bud(cid:352)et, 126 C cele, 126 ceny, 127 chirurg, 50 ci(cid:167)g(cid:175)a zmiana, 135 organizacji, 136 systemu, 135 Corbató, 111 cotygodniowe konferencje, 85 cz(cid:171)sto(cid:321)(cid:250), 283 D debugowanie, 37, 38 interaktywne, 164 komponentów, 162 systemowe, 165 systemu, 267, 270 decyzje, 259 diagram organizacji, 127 przep(cid:175)ywu, 187, 191 struktury programu, 188 dodawanie komponentów, 168 dokumentacja, 125, 152, 185, 262, 268, 273 dokumenty, 126 dla wydzia(cid:175)u uniwersytetu, 128 formalne, 129 w projekcie oprogramowania, 128 dostarczanie, 264, 273 drabinka awansów, 137 drugi pilot, 50 dyrektor, 99 techniczny, 98 Poleć książkęKup książkę 334 Legendarny osobomiesi(cid:200)c E efekt drugiego systemu, 73, 284 eksperyment Golda, 269 my(cid:321)lowy, 235 elastyczno(cid:321)(cid:250), 264 entropia, 141 ewolucja produktu, 23 F formalne definicje, 81 G generowanie formalnej definicji, 82 H Harel David, 232 harmonogram, 37, 43, 147, 126, 175, 271 Harr John, 108 hipoteza dokumentacji, 125, 262 I implementacje, 86 interfejs metaprogramowania, MPI, 311 WIMP, 284, 288 in(cid:352)ynieria oprogramowania, 199, 312 J jako(cid:321)(cid:250), 237 j(cid:171)zyk Ada, 208 j(cid:171)zyk wysokiego poziomu, 153, 206, 208, 268 K kamienie milowe, 174, 271 katastrofa, 173, 270 klasa, 209 kompilator, 109 komponenty zast(cid:171)pcze, 166 komputer dla asemblera, 150 dla kompilatora, 150 do debugowania, 267 docelowy, 147 roboczy, 149 komunikacja, 92, 256, 257 konflikt, 177 konserwacja programu, 109, 138 kontrola wielko(cid:321)ci systemu, 117 zmian, 167 koszty, 242, 260 konserwacji, 266 u(cid:352)ytkowania, 116 ksi(cid:167)(cid:352)ka prac projektu, 93, 258 kwantyfikacja aktualizacji, 168 zmian, 136 L LIFO, 96 Lukasik Steve, 231 M mened(cid:352)er, 40, 48 architektury, 65 implementacji, 65 projektu, 85, 267 metaprogram, 311 metaprogramista, 310 metaprogramowanie, 309 metoda top-down, 161 migawki, 163 minidecyzje, 256 model wodospadu, 289 MPI, metaprogramming interface, 311 Poleć książkęKup książkę Skorowidz 335 N narz(cid:171)dzia, 145, 216, 239, 267 programowe, 151 niewidoczno(cid:321)(cid:250), 205, 236, 264 O obs(cid:175)uga bibliotek, 150 odrzucanie, 264 ograniczenia wielko(cid:321)ci, 261 opis programu, 185 opó(cid:350)nienia, 270 oprogramowanie zafoliowane, 307 optymizm, 32, 232 organizacja, 92, 97, 259 drzewiasta, 259 gotowa na zmiany, 265 osobomiesi(cid:167)c, 31, 34, 253 P pakiety jako komponenty, 309 Parnas David, 292 peopleware, 300 pesymizm, 232 planowanie, 37 plik miniaturowy, 167 zast(cid:171)pczy, 167 podatno(cid:321)(cid:250) na zmiany, 204 podbiblioteki aktualnej wersji, 151 podejmowanie decyzji, 105, 259 podr(cid:171)cznik, 80 podzia(cid:175) czasu, 207 zada(cid:302), 35 polecenia, 286 ponowne wykorzystanie kodu, 242, 244 poprawki, 266 Portman Charles, 107 prawo Brooksa, 299 producent, 98 produkt programowania systemowego, 22–24 produktywno(cid:321)(cid:250), 111, 237 programowanie automatyczne, 213 graficzne, 214 interaktywne, 154, 268 samodokumentuj(cid:167)ce, 274 strukturalne, 162, 269 wysokiego poziomu, 273 zorientowane obiektowo, 209, 240 programy samodokumentuj(cid:167)ce, 189 uzupe(cid:175)niaj(cid:167)ce, 167 projekt pilota(cid:352)owy, 263 systemu, 255 projektanci, 222 projektowanie metod(cid:167) top-down, 161 projekty w(cid:171)druj(cid:167)ce, 301 propozycja Millsa, 50 protokó(cid:175) telefoniczny, 87 prototyp systemu, 220 przemys(cid:175) oprogramowania, 307 przewidywania, 127 przydzia(cid:175) przestrzeni, 127 przypadek, 229 przypadki testowe, 165 R realizm, 232 redaktor, 51 regulowanie wielko(cid:321)ci programu, 119 rekurencja architektów, 281 reprezentacja, 121 rewolucja mikrokomputerów, 306 rozrost funkcji, 282 rozwi(cid:167)zania pilota(cid:352)owe, 134 rozwój inkrementalny, 221 Poleć książkęKup książkę 336 Legendarny osobomiesi(cid:200)c S samodokumentuj(cid:167)cy si(cid:171) program, 192 sekretarz, 51 separacja architektury od implementacji, 280 skalowanie, 55, 134 s(cid:175)owniki, 245 specjalista j(cid:171)zykowy, 53 specyfikacja, 80, 126 spotkania, 84, 93 spójno(cid:321)(cid:250) koncepcji, 60, 279, 284 stacje robocze, 216 struktura komunikacji, 259 symulator, 149 wydajno(cid:321)ci, 152 system dokumentacji, 152 edycji tekstu, 268 ekspercki, 211 operacyjny, 308 programowy, 274 szkieletowy, 291 szacowanie tchórzliwe, 38 szacunki, 127 sztuczna inteligencja, 210 szybkie prototypowanie, 294 szybko(cid:321)(cid:250) debugowania, 110 programowania, 110 (cid:316) (cid:321)rodowiska programistyczne, 216 T techniki regulowania wielko(cid:321)ci, 119 szacowania, 32 tester, 52 testowanie produktu, 87 specyfikacji, 160 testy systemowe, 37 translator, 109 tworzenie dokumentacji, 189 kodu, 38 oprogramowania model wodospadu, 289 model inkrementalno – progresywnych ulepsze(cid:302), 291 przyrostowe, 294 prototypów, 219 systemu szkieletowego, 291 U uproduktowienie programu, 252 urz(cid:171)dnik, 51 us(cid:175)ugi danych, 149 uszczegó(cid:175)awianie wymaga(cid:302), 219 utrzymywanie programu, 265 u(cid:352)ytkownik, 282, 310 u(cid:352)ywanie zdebugowanych komponentów, 165 W weryfikacja programu, 215 wielko(cid:321)(cid:250) oprogramowania, 116 wska(cid:350)niki produktywno(cid:321)ci, 238 wymagania, 219 dokumentacyjne, 273 wymiana informacji, 36 Z zabezpieczanie definicji, 160 zespó(cid:175), 53, 254, 267 zgodno(cid:321)(cid:250), 204 zintegrowane (cid:321)rodowiska programistyczne, 207 z(cid:175)o(cid:352)ono(cid:321)(cid:250), 202, 231 zmniejszanie skali konfliktu, 177 zrzuty pami(cid:171)ci, 163 zyski, 242 Poleć książkęKup książkę
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Legendarny osobomiesiąc. Opowieści o inżynierii oprogramowania. Wydanie II
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: