Blog naukowy z Warszawy. Zdobądź wiedzę z języków obcych, nauki śpiewu...

Dane Portmana i Arona

Charles Portman, szef pionu oprogramowania do ICL w Computer Equipment Organization (Northwest) w Manchesterze, podzielił się też swoimi refleksjami5. Ustalił, że jego zespoły programowania przekraczają ustalone terminy mniej więcej o połowę. Każde zadanie zajmuje około dwukrotnie więcej czasu niż pierwotnie przyjmowano. Szacunków dokonywano bardzo starannie. Przeprowadzały je doświadczone zespoły, obliczające osobogodziny na kilkaset podzadań na wykresie PERT. Kiedy zaczęły się pojawiać opóźnienia, Portman zobowiązał zespoły do prowadzenia dokładnych dzienników wykorzystania czasu. Wynikało z nich, iż błędy w szacunkach brały się stąd, że tak naprawdę na programowanie i uruchamianie programów zespoły wykorzystywały zaledwie około 50 procent tygodniowego czasu pracy. Resztę pochłaniały przestoje maszyn, krótkie inne priorytetowe prace, narady, praca papierkowa, sprawy firmy, choroby, zwolnienia itp. Krótko mówiąc, w szacunkach przyjmowano nierealną liczbę godzin pracy technicznej na osoborok. Moje osobiste doświadczenia w pełni to potwierdzają6.

Joel Aron, szef działu technik systemowych IBM w Gaithersburgu, w stanie Maryland, badał wydajność programistów w pracach nad dziewięcioma dużymi systemami („duży” oznacza w skrócie więcej niż 25 programistów i 30 000 dostarczanych instrukcji)7. Podzielił te systemy według liczby interakq’i między programistami (oraz częściami systemu) i otrzymał następujące wyniki wydajności: bardzo mało interakcji 10 000 instrukcji na osoborok pewna liczba interakcji 5000 wiele interakcji 1500

W podanych osobolatach nie uwzględniono działań pomocniczych i testowania systemu, a jedynie projektowanie i programowanie. Kiedy liczby te podzieli się przez 2, żeby uwzględnić testowanie systemu, będą zgodne z danymi Harra.

Podobne Artykuły

Zostaw odpowiedź

Twoj adres e-mail nie bedzie opublikowany.