Blog naukowy z Warszawy. Zdobądź edukację z języka francuskiego, nauki gry na perkusji!

Konwencjonalny schemat organizacyjny

Nadal należy zaznaczać zmiany w tekście i podawać daty ich wprowadzania. Nadal potrzebne jest elektroniczne podsumowanie zmian w trybie LIFO.. Parnas twierdzi, że dążenie do tego, żeby wszyscy widzieli wszystko, jest całkowicie błędne. Części należy hermetyzować: programista powinien mieć dostęp tylko do organizacji wewnętrznej swojej części. Należy udostępniać jedynie interfejsy. Teza Parnasa to przepis na katastrofę. [Parnas w pełni mnie później przekonał i doprowadził do tego, że całkowicie zmieniłem zdanie].

Organizowanie pracy ma na celu ograniczanie komunikacji i koordynacji do niezbędnych rozmiarów. Organizowanie pracy nad danym przedsięwzięciem programistycznym obejmuje podział pracy i specjalizację, co prowadzi do ograniczenia komunikacji.

Konwencjonalny schemat organizacyjny w kształcie drzewa przedstawia strukturę władzy, zgodnie z którą nikt nie może być sługą dwóch panów. Struktura komunikacji jest siecią, a nie drzewem: trzeba zatem opracowywać różnego rodzaju specjalne mechanizmy organizacyjne („przerywane linie”), żeby przezwyciężyć komunikacyjne niedociągnięcia organizacji o strukturze drzewiastej.

Prace nad każdym podprojektem wymagają dwóch stanowisk kierowniczych: producenta i dyrektora technicznego, czyli architekta. Funkcje te są zupełnie odmienne i do pełnienia ich potrzeba zupełnie innych zdolności. Między producentem a dyrektorem technicznym zachodzą z powodzeniem trzy relacje:

– producent i dyrektor to jedna i ta sama osoba:

– producent jest szefem, a dyrektor jego prawą ręką:

– dyrektor jest szefem, a producent jego prawą ręką.

Zapowiadanie działań

Nie da się dokładnie oszacować całkowitej pracochłonności ani czasu realizacji przedsięwzięcia programistycznego przez proste oszacowanie czasu kodowania i zastosowanie odpowiednich wskaźników w odniesieniu do innych części zadania.

Dane dotyczące budowy małych oddzielnych programów nie sprawdzają się w wypadku opracowywania systemów. Pracochłonność programowania rośnie proporcjonalnie do potęgi rozmiarów programu.

W niektórych opublikowanych badaniach podano, że ten wykładnik potęgi wynosi około 1,5. [Dane Boehma nie sq z tym zgodne: w tym wypadku wykładnik wynosi od 1,05 do 1,2]1. Dane ICL, przytoczone przez Portmana, wykazują, że programiści zatrudnieni na pełnym etacie poświęcają jedynie 50 procent czasu pracy na programowanie i uruchamianie programów, a resztę na inne zadania ogólne.

Dane IBM, przytoczone przez Arona, wykazują, że wydajność programistów waha się od 1,5 do 10 K wierszy kodu na osobo- rok jako funkcja liczby interakcji między częściami systemu. Dane Bell Telephone Laboratories, przytoczone przez Harra, wykazują, że wydajność programistów w gotowych produktach wynosi w pracach nad systemami operacyjnymi około 0,6 K wierszy kodu na osoborok, a w pracach nad kompilatorami około 2,2.

Dane dotyczące OS/360, przytoczone przez Brooksa, są zgodne z danymi Harra: 0,6-0,8 K wierszy kodu na osoborok w pracy nad systemami operacyjnymi, a 2-3 K w pracach nad kompilatorami. Dane dotyczące Project MULTICS w MIT, przytoczone przez Corbató, wykazują, że wydajność programistów w pracach nad kombinacją systemów operacyjnych i kompilatorów wynosi 1,2 K wierszy kodu na osoborok. Trzeba jednak zaznaczyć, że w tym wypadku chodzi o wiersze kodu PL/I, a w wypadku innych badań o wiersze kodu asemblerów! Wydajność wydaje się stała, jeśli chodzi o instrukcje podstawowe. Wydajność programowania można zwiększyć aż pięciokrotnie, jeżeli używa się odpowiedniego języka wysokiego poziomu.

Podobne Artykuły

Zostaw odpowiedź

Twoj adres e-mail nie bedzie opublikowany.