Często programiści, szczególnie niedoświadczeni, czują się zdezorientowani, gdy są proszeni o ustalenie terminów wykonania zadań. Jednak umiejętność planowania to bardzo przydatna i niezbędna umiejętność, która pomaga nie tylko w pracy, ale także w życiu. Postanowiliśmy zapytać ekspertów, jak nauczyć się prawidłowo planować i terminowo realizować projekty.

Krótkie wnioski znajdują się na końcu artykułu.

Programista zazwyczaj musi wziąć pod uwagę kilka parametrów na raz, aby oszacować czas potrzebny na wykonanie zadania:

1. Doświadczenie w wykonywaniu tego typu zadań i pracy z tym stosem technologii. Jeśli musisz zrobić coś całkowicie nowego, musisz zachować szczególną ostrożność przy ocenie.
2. Doświadczenie w pracy z tym klientem. Znając klienta można z grubsza przewidzieć dodatkowe wymagania i zakres zmian.
3. Jakość kodu, z którym będziesz pracować. Jest to najbardziej wpływowy czynnik, przez który wszystko może zająć dużo czasu i generalnie nie przebiegać zgodnie z planem. Jeśli projekt zawiera testy, wszędzie są tylko wyraźne zależności, a funkcjonalność jest dobrze izolowana, wszystko nie jest takie straszne. Jest znacznie gorzej, jeśli masz do czynienia ze starszym kodem bez testów lub z kodem przeciążonym ukrytymi zależnościami. Rzeczy takie jak „magiczne funkcje” (kiedy trudno zobaczyć końcowy stos wywołań z kodu) i powielanie kodu (kiedy trzeba edytować kilka niezależnych sekcji, aby zmienić jakąś funkcjonalność) również mogą skomplikować sprawę.

Aby nauczyć się odpowiednio szacować terminy prac, trzeba stale ćwiczyć. Na początku swojej pracy postępowałem dokładnie tak: szacowałem czas wykonania każdego przychodzącego zadania, nawet jeśli nikt tego nie wymagał, a następnie sprawdzałem, jak dokładnie udało mi się trafić w swój szacunek. Wykonując zadanie, notował, które czynności trwały dłużej. Jeśli coś znacznie wydłużało ten okres, zapamiętywałem ten moment i brałem to pod uwagę w kolejnych ocenach.

Do obiektywnej oceny czasu potrzebnego wyłącznie na pracę należy doliczyć niewielki margines na sytuacje siły wyższej. Często ocenia się go jako procent wykonania zadania głównego, jednak dla każdego jest on inny: niektórzy dodają 20% czasu, inni - 10%, a jeszcze inni - 50%.

Przydatna jest także analiza przyczyn przekroczenia terminów po każdym poważnym ich naruszeniu. Jeśli brakuje Ci kwalifikacji, musisz popracować nad swoimi słabymi punktami. Jeśli problem miał charakter organizacyjny, dowiedz się, co uniemożliwiło mu normalne działanie.

Promuj Demot

, dyrektor techniczny centrum innowacyjnych technologii i rozwiązań „Jet Infosystems”

Wiele artykułów poświęconych jest metodom oceny pracochłonności projektu, z uwzględnieniem czasu pracy i poszczególnych zadań. Jednak nadal powoduje to konflikty zarówno w zespole projektowym, jak i podczas komunikacji z klientem.

Głównym pomocnikiem w ocenie jest doświadczenie. Spróbuj w jakiś sposób porównać nowe zadanie z już wykonanymi. Jeśli sporządzasz raport, spójrz, ile czasu zajęło przygotowanie podobnego raportu w przeszłości. Jeśli robisz coś nowego, spróbuj podzielić to na znane części i je ocenić. Jeśli zadanie jest zupełnie nowe, przeznacz czas na naukę (a jeszcze lepiej, skoordynuj ten czas z osobą wyznaczającą zadanie).

Zwróć uwagę na etapy towarzyszące – jeśli potrzebujesz opracować usługę, to ocena musi obejmować także testy jednostkowe (a może nie tylko testy jednostkowe), przygotowanie danych testowych zajmie trochę czasu. Warto rozważyć integrację z innymi usługami itp. Daj czas na poprawienie usterek, które znajdziesz samodzielnie lub przy pomocy testerów. Dużo czasu można zmarnować na „niewidzialne” zadania. Na przykład istnieje ocena pod kątem rozwoju i ocena pod kątem testów, ale przekazanie artefaktu do testów może wiązać się z rozmieszczeniem stanowisk. Dlatego ważne jest, aby mentalnie zwizualizować cały proces, aby niczego nie przeoczyć.

Po określeniu złożoności należy uwzględnić w kalendarzu nową pracę, nie zapominając o innych zadaniach i czynnościach, które przebiegają równolegle.

I nie zapominaj, że plany są bezużyteczne, ale planowanie jest bezcenne. Naucz się dostosowywać plany w odpowiednim czasie, informuj wszystkie zaangażowane osoby i eskaluj działania w odpowiednim czasie, aby niedotrzymanie terminów nie było dla nikogo zaskoczeniem.

Promuj Demot

Pytanie, na które nie da się odpowiedzieć w krótkiej formie. Gdyby to było proste, to problemu niedotrzymania terminów nie byłoby.

Aby terminy rozwoju były bardziej przewidywalne, musimy najpierw zrozumieć powody, dla których programiści cały czas popełniają błędy.

Pierwszym powodem jest to, że większość zadań wykonywanych przez programistę jest w takim czy innym stopniu unikalna. Oznacza to, że najprawdopodobniej programista będzie wykonywał podobne zadanie po raz pierwszy. Nie ma pojęcia, ile czasu zajmie ta praca. Jeśli jest to programista z solidnym doświadczeniem i miał do wykonania podobne zadanie, jego ocena będzie bliższa rzeczywistości.

Posłużmy się prostą analogią – jeśli nigdy nie kopałeś rowu, nie jesteś w stanie dokładnie określić, ile czasu zajmie Ci wykopanie rowu o szerokości 30 cm, głębokości 60 cm i długości 20 metrów. Jeśli kopałeś już wcześniej, szacunkowy czas pracy będzie znacznie bliższy faktycznemu czasowi pracy.

Drugim powodem jest to, że programiści są z natury optymistami. Oznacza to, że rozważając zadanie, wybierając opcję jego realizacji i oceniając ulepszenia, programista oczekuje, że wszystko będzie działać zgodnie z jego oczekiwaniami. I nie myśli o problemach, jakie napotka po drodze. Często nie jest w stanie ich przewidzieć. Na przykład istnieje zadanie, które programista może wykonać, korzystając z biblioteki oprogramowania typu open source innej firmy. Na etapie oceny znalazł go w Internecie, przeczytał opis – mu odpowiada. I nawet poprawnie oszacował ilość pracy, jaką musiałby włożyć, aby zwiększyć wykorzystanie tej biblioteki. Ale wcale nie przewidział, że w tej bibliotece w środowisku jego oprogramowania pojawi się błąd.

Programista będzie musiał nie tylko wbudować wykorzystanie biblioteki w swój kod, ale także naprawić błąd w samej bibliotece. I często programista nie daje czasu na poprawienie swoich błędów. Statystyki pokazują, że testowanie i naprawianie błędów może zająć około 50% czasu poświęconego na kodowanie. Liczba ta zależy od kwalifikacji programisty, środowiska i zastosowanych praktyk programistycznych (na przykład testy jednostkowe znacznie skracają ten czas, a końcowy czas trwania/pracochłonność zadania programistycznego jest mniejsza).

Jeśli wrócimy do analogii z koparką, to kopacz nie spodziewał się, że jego łopata się złamie i będzie musiał spędzić dwie godziny na szukaniu nowego cięcia.

Trzeci powód to nieprzewidziane wymagania. W żadnym innym obszarze produkcji materiałów, z którym klienci tak chętnie porównują tworzenie oprogramowania, nie ma takiego napływu nowych wymagań. Wyobraźcie sobie przejazd koparki, który wykopał 19 z 20 metrów i usłyszał od klienta życzenie, aby rów nie szedł po linii prostej, ale po wężu o długości ramienia 97 centymetrów.

Jak sobie z tym wszystkim poradzić i jak żyć w warunkach takiej niepewności? Ograniczanie niepewności i budowanie rezerw czasu.

Najprostszym sposobem na zbliżenie swoich oczekiwań do rzeczywistości jest skorzystanie z żartobliwej reguły Pi. Otrzymawszy oszacowanie od dewelopera (pod względem czasu lub pracochłonności), należy je pomnożyć przez Pi (= 3,14159). Im bardziej doświadczony deweloper przeprowadził ocenę, tym niższy może być ten współczynnik.

Obowiązkowa jest praktyka rozkładania pierwotnego problemu na małe zadania trwające nie dłużej niż 4 godziny. Im bardziej szczegółowa jest dekompozycja, tym większe są szanse, że oszacowanie będzie zbliżone do rzeczywistej złożoności/czasu trwania.
Jeśli wrócimy do alokacji rezerwy, to czas ten powinien zostać przydzielony na koniec projektu. Złą praktyką jest tworzenie rezerwy i dołączanie jej do każdego zadania. Ściśle przestrzegane jest prawo Parkinsona „Praca wypełnia cały przydzielony jej czas”.

Reasumując w skrócie, w celu prawidłowego określenia terminów wykonania prac przydatne będą następujące działania:

• przeprowadzić rozkład pracy, dzieląc zadanie na możliwie szczegółowe etapy;
• przeprowadzić prototypowanie;
• ograniczyć realizację wcześniej nieprzewidzianych wymagań. Nie oznacza to, że nie trzeba ich wykonywać, ale wskazane jest podkreślenie tych wymagań i uzgodnienie z klientem zmian w zakresie harmonogramu i kosztów ich wdrożenia;
• wziąć pod uwagę czas wymagany do ustabilizowania roztworu;
• stosować praktyki poprawiające jakość kodu, takie jak pisanie testów jednostkowych;
• utworzyć rezerwę ogólną.

No cóż, pamiętaj, że jeśli fakt przekracza Twoje szacunki o 30%, to jest to bardzo dobry wynik.

Promuj Demot

Do jak najtrafniejszej oceny potrzebne jest doświadczenie w realnym rozwoju, a konkretnie w konkretnym obszarze. Ale są też ogólne zasady, które pomogą Ci uniknąć błędów w planowaniu i problemów w dostawie pracy do klienta. Opisałbym te zasady w ten sposób.

Najpierw musisz zrozumieć problem. Wydaje się to oczywiste i nie ma bezpośredniego związku z szacunkami czasowymi, ale w rzeczywistości jest to kwestia kluczowa. Nawet w przypadku poważnych, dużych projektów jednym z głównych czynników niepowodzeń i opóźnień jest problem w określeniu wymagań. Dla początkujących programistów jest to niestety poważny problem – nie czytają specyfikacji technicznych lub czytają i rozumieją bardzo wybiórczo (na dziesięć punktów zapamiętali i wypełnili pięć, a resztę zapamiętali przy przesyłaniu wyniku). Oczywiste jest, że źle zrozumianego zadania nie da się wykonać poprawnie i na czas.

Następnym krokiem jest oszacowanie samego czasu rozwoju. Osobliwością programowania jest to, że nie ma absolutnie identycznych zadań. Dzięki temu nasza praca jest ciekawsza, ale szacowanie terminów jest trudniejsze. Świetnie sprawdza się tu rozkład, tj. podzielenie złożonego, unikalnego problemu na sekwencję małych, znanych podzadań. A każdy z nich można już w miarę adekwatnie ocenić w godzinach. Dodajmy szacunki podzadań i otrzymajmy oszacowanie dla całego zadania.

Z reguły taki kosztorys obejmuje jedynie koszty samego kodowania. Jest to oczywiście najważniejsza część opracowania, ale nie jedyna (i często nie najbardziej obszerna). Kompletna realizacja zadania obejmuje również przeczytanie i wyjaśnienie specyfikacji, spotkania ze współpracownikami lub klientem, debugowanie i testowanie, sporządzenie dokumentacji, dostarczenie wyniku (demonstracja klientowi i ewentualne modyfikacje na podstawie jego uwag). Tylko doświadczenie powie Ci dokładnie, ile czasu zajmie Ci wykonanie tych czynności. Na początku ważne jest, aby przynajmniej nie zapomnieć o uwzględnieniu ich w obliczeniach i możesz poprosić bardziej doświadczonych kolegów o przybliżone oszacowanie czasu.

Zatem wyceniamy koszty pracy związanej z kodowaniem, dodajemy oszacowanie kosztów dodatkowej pracy - i otrzymujemy wymagany szacunek czasu wykonania zadania. Ale to nie wszystko! Należy wskazać planowany termin zakończenia zadania. Błędem byłoby po prostu dzielenie kosztów pracy (w godzinach) przez 8 godzin i dodawanie ich do aktualnej daty. W praktyce programista nigdy (no dobra, prawie nigdy) nie pracuje w 100% nad jednym konkretnym zadaniem. Na pewno poświęcisz czas na inną pracę - ważną, ale nie związaną bezpośrednio z główną. Na przykład pomaganie współpracownikom, szkolenia, pisanie raportów itp. Zazwyczaj podczas planowania uważa się, że 60-70% czasu pracy spędza się bezpośrednio na bieżącym projekcie. Dodatkowo musisz liczyć się z możliwymi opóźnieniami, które uniemożliwią ci ciągłą pracę nad zadaniem. Na przykład, jeśli w tym celu musisz wchodzić w interakcję z innymi ludźmi (współpracownikami, klientami), weź pod uwagę ich dostępność, harmonogram pracy itp.

Oto podstawowe zasady, które moim zdaniem pomogą deweloperowi uniknąć problemów w szacowaniu i dotrzymywaniu terminów. Ponadto kluczowe jest gromadzenie własnego doświadczenia zarówno w realizacji zadań, jak i ocenie. Przykładowo, bardzo przydatne jest po wykonaniu zadania porównanie wstępnego oszacowania z faktycznymi terminami i wyciągnięcie wniosków na przyszłość. I oczywiście warto studiować doświadczenia innych ludzi. Polecam książki na ten temat autorstwa S. McConnella „Ile kosztuje projekt oprogramowania” i S. Arkhipenkowa „Wykłady z zarządzania projektami oprogramowania”.

Promuj Demot

Przy szacowaniu i planowaniu terminów należy:

1. Rozłóż zadanie na małe, funkcjonalne elementy w taki sposób, aby było jasne, ile czasu zajmie opracowanie każdego z nich.
2. Równolegle z rozkładem z pewnością pojawią się dodatkowe pytania dotyczące funkcjonalności, która nie została opisana w opisie problemu. Uzyskanie odpowiedzi na takie pytania jest konieczne, ponieważ wiąże się to bezpośrednio z zakresem prac, a co za tym idzie, z harmonogramem.
3. Do oceny końcowej dodaj określony procent ryzyka. Ustala się to empirycznie. Możesz zacząć na przykład od ryzyka 10–15%.
4. Dowiedz się, ile godzin dziennie programista jest skłonny poświęcić na wykonanie zadania.
5. Ostateczny kosztorys dzielimy przez liczbę godzin, które przeznaczyliśmy dziennie i otrzymujemy liczbę dni wymaganych na realizację.
6. Skupiamy się na kalendarzu i wymaganej liczbie dni do wykonania. Bierzemy pod uwagę weekendy i inne dni, w których programista nie będzie mógł pracować nad zadaniem, a także datę rozpoczęcia pracy (programista nie zawsze jest gotowy do podjęcia zadania tego samego dnia). W ten sposób otrzymujemy datę rozpoczęcia i zakończenia pracy.

Promuj Demot

W naszej firmie planowanie zadań zawsze przebiega przez kilka etapów. Od strony biznesowej formułujemy 5-6 celów strategicznych na rok. Są to zadania wysokiego szczebla, np. zwiększające jakiś parametr o tyle procent. Następnie różne działy firmy formułują zadania biznesowe dla wszystkich zespołów IT. Terminy wykonania tych zadań otrzymują wstępny przybliżony szacunek, który często tworzą wszyscy członkowie zespołu – menadżer, analityk, programista i tester. Po otrzymaniu tej oceny firma ustala priorytety zadań w oparciu o cele strategiczne firmy. Pomagają w tym przekrojowe cele strategiczne, dzięki którym staje się oczywiste, że wszyscy pracujemy dla jakiejś wspólnej sprawy, nie ma sytuacji, w której ktoś tylko ciągnie w swoją stronę. Zbieramy sprinty z zadań dokładnie oszacowanych pod względem terminów realizacji. Dla niektórych zespołów są one kwartalne, dla innych miesięczne. W przypadku kilku zadań, które według wstępnych szacunków wejdą w kolejny sprint, zespoły podają dokładny kosztorys. Zadania duże dzielimy na zadania niższego szczebla, za każde z nich odpowiada konkretny wykonawca i to on wystawia trafną ocenę.

Na tym etapie ważne jest, aby nie zapomnieć o dodaniu rezerwy czasu na naprawę błędów, ponieważ tylko ci, którzy nic nie robią, nie popełniają błędów. Doskonale to rozumieją zarówno Właściciele Produktu, jak i klienci biznesowi. Jednocześnie wymagana ilość czasu musi być odpowiednia: nikt nie zrozumie programisty, który wyznacza zbyt długi termin dla prostego zadania, zostanie poproszony o uzasadnienie swojej decyzji. Najtrudniejszą rzeczą jest wyjaśnienie firmie, dlaczego refaktoryzacja wymaga czasu. Jesteśmy wdzięczni naszej firmie za to, że od czasu do czasu nam się to udaje, ponieważ ostatecznie refaktoryzacja prowadzi do uproszczenia infrastruktury i uporządkowania kodu, co zwiększa stabilność systemu i może znacznie przyspieszyć rozwój nowych funkcji.

Czasami nadal zdarzają się błędy w ocenie. Moim zdaniem dział rozwoju w dużych firmach z rozwiniętą infrastrukturą nie jest w stanie całkowicie tego uniknąć. W tym przypadku ważne jest, aby deweloper szybko poinformował swojego menedżera o tym, co się dzieje, a on z kolei zdążył ostrzec firmę i „odtworzyć” coś w ogólnych planach firmy. Praca w tym trybie jest o wiele bardziej poprawna, niż gorączkowe próbowanie w 3 dni zrobienia tego, co zajmuje 5, a potem tonięcie w dużej liczbie błędów, które powstały z powodu takiego pośpiechu.

Promuj Demot

Prawidłowa odpowiedź na obie części pytania [jak nauczyć się prawidłowo planować i realizować projekt na czas - Czerwony.] - doświadczenie. Nie ma innego sposobu, aby „poznać zen”. Zgodnie z teorią decyzji dokładne wnioski można wyciągnąć jedynie na podstawie analizy szeregu dostępnych już danych. Im więcej danych, tym dokładniejsza ostateczna prognoza i ocena.

Jak ujął to Herbert Shaw: „Doświadczenie jest szkołą, w której człowiek uczy się, jakim głupcem był wcześniej”. Prowadzi to do dość prostego wniosku: jeśli programista ma już doświadczenie korelujące z postawionym przed nim zadaniem, może na nim polegać, jeśli nie, może polegać na doświadczeniu swoich „kolegów”.

Następnie musisz zrozumieć, że bezpośrednie planowanie terminów to zadanie, z którym ludzie radzą sobie bardzo, bardzo słabo, szczególnie w fazie rozwoju. Przy szacowaniu terminów płatności za dobrą praktykę uważa się wprowadzenie „czynników korygujących” do pierwotnego szacunku. Wskaźnik ten może wynosić od 1,5 do 3, w zależności od doświadczenia programisty i sumy stopni niepewności zadań rozwiązywanych w ramach projektu.

Promuj Demot

Przy ustalaniu terminów ważne jest, aby wziąć pod uwagę wiele czynników.

Na przykład doświadczenie zawodowe. Jak dobrze rozumiesz zakres nadchodzących prac? Czy robiłeś już coś takiego? Oczywiste jest, że im więcej doświadczenia, tym szybciej praca zostanie ukończona.

Dobrze napisana specyfikacja techniczna odgrywa znaczącą rolę w ustalaniu terminów realizacji. W naszym regionie sytuacja jest z tym bardzo trudna. Często sam klient nie wie, czego chce, dlatego radzę spędzić dodatkowy dzień lub dwa, ale sprawić, aby klient miał jasne wyobrażenie o pożądanym rezultacie. Ważne jest, aby to zrozumienie było obustronne. I dopiero potem możesz zacząć negocjować kwotę i warunki.

Zawsze uwzględniaj także ryzyko. Początkującym polecam pomnożyć szacowany czas ukończenia przez dwa. W końcu lepiej jest dostarczyć projekt przed terminem i rozwijać się jako specjalista w oczach klienta, niż oddać go później i zrujnować swoją reputację.

Promuj Demot

Ogólnym zaleceniem jest to, że programista musi nauczyć się poprawnie rozkładać zadania, zawsze szukać możliwych pułapek, polegać na własnym doświadczeniu i nie zapomnieć w odpowiednim czasie ostrzec klientów i współpracowników, jeśli zadania nie można rozwiązać w określonym czasie rama.

Zbudowanie jasnego planu jest znacznie trudniejsze niż określenie terminu wykonania pojedynczego zadania. Jednocześnie ważne jest nie tylko terminowe oddanie projektu, ale także to, aby tworzony przez Ciebie system poprawnie rozwiązywał problemy biznesowe. Tutaj zespołom IT pomagają różne metodologie tworzenia oprogramowania: od RUP i MSF po SCRUM i inne formaty Agile. Wybór narzędzi jest bardzo szeroki, a wielu naszych klientów chce z góry zrozumieć, w jaki sposób będziemy z nimi pracować w projekcie, jakimi zasadami się kierujemy.

Nawiasem mówiąc, temat Agile staje się dziś bliski zarówno biznesowi, jak i nawet w indywidualnych projektach sektorowi publicznemu, ponieważ zasady tej metodologii umożliwiają bardzo szybką realizację projektów, zarządzając oczekiwaniami klientów w każdej iteracji. Przykładowo w zespole Agile praktycznie nie ma długich rozmów z klientem. Zapomnij o dziesiątkach stron opisujących niepotrzebne szczegóły techniczne, takie jak szybkość pojawiania się listy rozwijanej. Daj klientowi możliwość wypróbowania pośredniej wersji systemu, wtedy znacznie łatwiej będzie wam się zrozumieć.

Zespół Agile wspólnie wszystko planuje i określa optymalny poziom pracy, który będzie potrzebny do rozwiązania konkretnego problemu. Na przykład jedna z technik nazywa się „Planowaniem pokera”, gdzie każdy uczestnik anonimowo podaje swoją ocenę wymaganych kosztów pracy dla konkretnego zadania. Następnie zespół określa średnią wagę zadania w punktach fabularnych lub roboczogodzinach i rozdziela zadania według zasady „kto co lubi”. Jednocześnie codziennie zespół zbiera się na 15-minutowe spotkanie, podczas którego wszyscy w ciągu kilku minut omawiają stan swoich bieżących zadań, w tym zgłaszają wszelkie powstałe trudności. Zespół szybko naprawia wykryty problem, dzięki czemu Klient możliwie najszybciej patrzy na kolejny etap pracy programisty. Deweloperzy nie zwlekają z realizacją zadań z powodu niechęci do ponownego zawracania głowy zespołowi lub daremnych prób samodzielnego rozwiązania problemu, zabijając cenny czas. Nawiasem mówiąc, przy takich mini-statusach programiści chcą pokazać się z najlepszej strony, pokazać, że podchodzisz do swojej pracy odpowiedzialnie. To naprawdę motywuje i uczy samodyscypliny.

(czas od pracy wlicza się do czasu jej zakończenia w przypadku aktywności okresowej lub do momentu reakcji systemu i przekazania pierwszego użytkownika do wyjścia w przypadku aktywności interaktywnej); lub maksymalizacja sprawiedliwość(równa ilość czasu procesora dla każdego procesu lub bardziej ogólnie odpowiadające czasy w zależności od priorytetu i obciążenia każdego procesu). W praktyce cele te są często sprzeczne (np. przepustowość kontra opóźnienie), więc osoba planująca dokona odpowiedniego kompromisu. Preferencje mierzone są za pomocą jednego z powyższych kryteriów, w zależności od potrzeb i celów użytkownika.

OS/360 i następcy

AIX

W systemie AIX wersja 4 istnieją trzy możliwe ustawienia strategii planowania wątków:

• Najpierw pierwszy: po zaplanowaniu wątku z tą zasadą zostaje on zakończony, chyba że zostanie zablokowany, dobrowolnie zrzeknie się kontroli nad procesorem lub możliwe będzie uruchomienie wątku o wyższym priorytecie. Tylko wątki o stałym priorytecie mogą mieć zasady planowania FIFO.
• Round Robin: Jest to podobne do harmonogramu obwodów w systemie AIX wersja 3, który wykonuje cykle w oparciu o przedziały czasu co 10 ms. Kiedy wątek PP przejmuje kontrolę na końcu przedziału czasowego, przesuwa się na koniec kolejki wątków o tym samym priorytecie. Tylko wątki o stałym priorytecie mogą mieć zasady planowania okrężnego.
• INNE: Ta polityka jest zdefiniowana w implementacji przez POSIX1003.4a. W systemie AIX wersja 4 ta strategia jest zdefiniowana jako równoważna strategii RR, z tą różnicą, że ma zastosowanie do wątków o nieustalonym priorytecie. Ponowne obliczenie wartości priorytetu działającego wątku dla każdego przerwania oznacza, że ​​wątek może stracić kontrolę, ponieważ jego wartość priorytetu wzrosła powyżej wartości innego wątku. Jest to zachowanie występujące w systemie AIX wersja 3.

Wątkami interesują się przede wszystkim aplikacje, które obecnie składają się z wielu procesów asynchronicznych. Aplikacje te mogą lekko obciążać system, jeśli zostaną przekonwertowane na strukturę wielowątkową.

W systemie AIX 5 zaimplementowano następujące zasady planowania: FIFO, okrężne i uczciwe okrężne. Polityka FIFO składa się z trzech różnych implementacji: FIFO, FIFO2 i FIFO3. Zasada działania okrężnego w systemie AIX nosi nazwę SCHED_RR, a uczciwa zasada działania okrężnego nazywa się SCHED_OTHER.

Linuksa

Linux 2.4

Brain Fuck Scheduler (BFS), również stworzony przez Kolivasa, jest alternatywą dla CFS.

FreeBSD

FreeBSD wykorzystuje wielopoziomową kolejkę sprzężenia zwrotnego z priorytetami z zakresu 0-255. Wartości 0-63 są zarezerwowane dla przerwań, 64-127 dla górnej połowy jądra, 128-159 dla wątków użytkownika działających w czasie rzeczywistym, 160-223 dla wątków użytkowników z podziałem czasu i 224-255 dla bezczynnych wątków użytkowników. Podobnie jak Linux, używa aktywnej konfiguracji kolejki, ale ma także kolejkę bezczynną.

Wstęp

Celem warsztatów z organizacji produkcji jest poszerzenie i pogłębienie wiedzy teoretycznej, zaszczepienie umiejętności niezbędnych do rozwiązywania najczęściej spotykanych w praktyce problemów dotyczących organizacji i planowania produkcji.

Warsztat zawiera zadania z głównych części kursu. Na początku każdego tematu prezentowane są krótkie instrukcje metodologiczne i informacje teoretyczne, typowe problemy z rozwiązaniami oraz problemy do samodzielnego rozwiązania.

Obecność instrukcji metodologicznych i krótkich informacji teoretycznych w każdym temacie pozwala na wykorzystanie tego warsztatu do nauki na odległość.

Obliczanie czasu trwania cyklu produkcyjnego

Czas trwania cyklu produkcyjnego służy jako wskaźnik efektywności procesu produkcyjnego.

Cykl produkcji– okres przebywania przedmiotów pracy w procesie produkcyjnym od momentu uruchomienia surowców do momentu wydania gotowych wyrobów.

Cykl produkcyjny składa się z godziny pracy, podczas którego wydatkowana jest praca, oraz czasy przerw. Przerwy, w zależności od przyczyn, które je spowodowały, można podzielić na:

1) włączone naturalny lub technologiczne – są one zdeterminowane charakterem produktu;

2) organizacyjny(przerwy między zmianami).

Na czas trwania cyklu produkcyjnego składają się następujące elementy:

Cykl T = T te + T zjada + T tr + T k.k. + T m.o. + T m.ts.

Gdzie T te– czas operacji technologicznych;

nie je - czas procesów naturalnych (suszenie, schładzanie itp.);

t tr – czas transportu przedmiotów pracy;

t k.k. – czas kontroli jakości;

t m.o – czas opieki międzyoperacyjnej;

t m.c. – czas przechowywania w magazynach międzybranżowych;

(T trzy T k.k. można łączyć z T m.o).

Obliczanie czasu cyklu produkcyjnego zależy od rodzaju produkcji. W produkcji masowej o długości cyklu produkcyjnego decyduje czas, w którym produkt znajduje się w produkcji, tj.

Cykl T = T w M,

Gdzie T V– skok zwolnienia;

M- liczba miejsc pracy.

Pod zwolnić skok konieczne jest zrozumienie odstępu czasu pomiędzy wypuszczeniem jednego wyprodukowanego produktu a następnego produktu.

Skok zwolnienia jest określony przez wzór

tin = Teff/V,

Gdzie Tef– efektywny fundusz czasu pracy pracownika za okres rozliczeniowy (zmiana, dzień, rok);

W– wielkość produkcji za ten sam okres (w jednostkach naturalnych).

Przykład: T cm = 8 godzin = 480 min; T na = 30 minut; → Teff = 480 – – 30 = 450 min.

B = 225 szt.; → T cal = 450/225 = 2 min.

W produkcji seryjnej, gdzie przetwarzanie odbywa się partiami, czas trwania cyklu technologicznego określa się nie na jednostkę produktu, ale na całą partię. Ponadto w zależności od sposobu wprowadzenia partii do produkcji uzyskujemy różne czasy cykli. Istnieją trzy sposoby przemieszczania produktów w produkcji: sekwencyjny, równoległy i mieszany (szeregowo-równoległy).

I. Na sekwencyjny Podczas przenoszenia części każda kolejna operacja rozpoczyna się dopiero po zakończeniu poprzedniej. Czas trwania cyklu dla sekwencyjnego ruchu części będzie równy:

Gdzie N – liczba części przetwarzanej partii;

t sztI- stawka akordowa za operację;

C ja– liczba stanowisk pracy na 1 I operacja;

M– liczba operacji procesu technologicznego.

Podawana jest partia produktów składająca się z 5 sztuk. Partia przechodzi kolejno przez 4 operacje; czas trwania pierwszej operacji wynosi 10 minut, drugiej 20 minut, trzeciej 10 minut, czwartej 30 minut (ryc. 1).

Obrazek 1

T cykl = T ostatni = 5·(10+20+10+30) = 350 min.

Sekwencyjna metoda ruchomych części ma tę zaletę, że zapewnia pracę sprzętu bez przestojów. Ale jego wadą jest to, że czas trwania cyklu produkcyjnego w tym przypadku jest najdłuższy. Ponadto na placach budowy powstają znaczne zapasy części, co wymaga dodatkowej powierzchni produkcyjnej.

II. Na równoległy Podczas przemieszczania partii poszczególne części nie są zatrzymywane na stanowiskach pracy, ale pojedynczo przekazywane są natychmiast do kolejnej operacji, nie czekając na zakończenie obróbki całej partii. Zatem przy równoległym ruchu partii części, na każdym stanowisku pracy wykonywane są jednocześnie różne operacje na różnych częściach tej samej partii.

Czas przetwarzania partii z równoległym ruchem produktów jest znacznie skrócony:

dł .

Gdzie n n– liczba części w partia transferowa(partia transportowa), tj. liczba produktów jednocześnie przeniesionych z jednej operacji do drugiej;

Długość – najdłuższy cykl pracy.

Przy równoległym uruchamianiu partii produktów, części całej partii przetwarzane są w sposób ciągły tylko na tych stanowiskach pracy, gdzie długie operacje następują po krótkich. W przypadkach, gdy krótkie operacje następują po długich, tj. dłużej (w naszym przykładzie trzecia operacja), operacje te wykonywane są w sposób nieciągły, tj. sprzęt jest nieczynny. W tym przypadku partia części nie może zostać przetworzona natychmiast, bez opóźnień, ponieważ poprzednia (długa) operacja na to nie pozwala.

W naszym przykładzie: N= 5, T 1 = 10; T 2 = 20; T 3 = 10; T 4 = 30; Z= 1.

T para = 1·(10+20+10+30)+(5-1)·30=70+120 = 190 min.

Rozważmy schemat równoległego ruchu części (ryc. 2):

Rysunek 2

III. Aby wyeliminować przerwy w przetwarzaniu poszczególnych części partii we wszystkich operacjach, należy zastosować równoległo-szeregowy Lub mieszany metoda uruchomienia, w której części (po obróbce) przekazywane są do kolejnej operacji pojedynczo lub w formie partii „transportowych” (kilka sztuk) w taki sposób, aby wykonanie operacji nie zostało przerwane na żadnym stanowisku pracy. W metodzie mieszanej ciągłość przetwarzania pobierana jest z metody sekwencyjnej, a przejście części z operacji do operacji bezpośrednio po jej obróbce z metody równoległej. W przypadku mieszanej metody uruchomienia produkcji czas trwania cyklu określa wzór

rdzeń .

gdzie jest kor. – najkrótszy cykl operacyjny (z każdej pary sąsiadujących ze sobą operacji);

M-1 – liczba kombinacji.

Jeżeli kolejna operacja jest dłuższa od poprzedniej lub równa w czasie, to operacja ta rozpoczynana jest indywidualnie, natychmiast po przetworzeniu pierwszej części w operacji poprzedniej. Jeśli natomiast kolejna operacja jest krótsza od poprzedniej, wówczas podczas przenoszenia sztuk występują tu przerwy. Aby im zapobiec, należy zgromadzić rezerwę transportową o takiej objętości, która zapewni pracę przy kolejnej operacji. Aby praktycznie znaleźć ten punkt na wykresie należy przenieść ostatnią część wsadu i przesunąć czas jej wykonania w prawo. Czas przetwarzania wszystkich pozostałych części w partii jest wykreślony po lewej stronie wykresu. Początek realizacji pierwszej części wskazuje na moment, w którym należy przenieść zaległości transportowe z poprzedniej operacji do tej operacji.

Jeśli sąsiednie operacje mają ten sam czas trwania, wówczas tylko jedna z nich jest uważana za krótką lub długą (ryc. 3).

Rysunek 3

T ostatnie pary = 5·(10+20+10+30)-(5-1)·(10+10+10) = 350-120 = 230 min.

Główne sposoby na skrócenie czasu cyklu produkcyjnego to:

1) Zmniejszenie pracochłonności wytwarzania wyrobów poprzez poprawę wykonalności wytwarzanego projektu, wykorzystanie komputerów i wprowadzenie zaawansowanych procesów technologicznych.

2) Racjonalna organizacja procesów pracy, organizacja i utrzymanie stanowisk pracy w oparciu o specjalizację i współpracę, szeroką mechanizację i automatyzację produkcji.

3) Ograniczenie różnorodnych planowanych i nieplanowanych przerw w pracy w oparciu o racjonalne wykorzystanie zasad naukowej organizacji procesu produkcyjnego.

4) Przyspieszenie reakcji w wyniku wzrostu ciśnienia, temperatury, przejścia do procesu ciągłego itp.

5) Usprawnianie procesów transportu, magazynowania i kontroli oraz łączenie ich w czasie z procesem przetwarzania i montażu.

Skrócenie czasu trwania cyklu produkcyjnego jest jednym z poważnych zadań organizacji produkcji, ponieważ wpływa na obrót kapitału obrotowego, zmniejszając koszty pracy, zmniejszając powierzchnię magazynową, potrzebę transportu itp.

Zadania

1 Określ czas trwania cyklu przetwarzania 50 części z sekwencyjnymi, równoległymi i szeregowo-równoległymi rodzajami ruchu w procesie produkcyjnym. Proces obróbki części składa się z pięciu operacji, których czas trwania wynosi odpowiednio min: T 1 =2; T 2 =3; T 3 =4; T 4 =1; T 5 = 3. Druga operacja wykonywana jest na dwóch maszynach, a każda kolejna na jednej. Wielkość partii transferowej wynosi 4 sztuki.

2 Określ czas trwania cyklu przetwarzania 50 części przy ruchach sekwencyjnych, równoległych i szeregowo-równoległych w procesie produkcyjnym. Proces obróbki części składa się z czterech operacji, których czas trwania wynosi odpowiednio min: T 1 =1; T 2 =4; T 3 =2; T 4 = 6. Czwarta operacja jest wykonywana na dwóch maszynach, a każda z pozostałych na jednej. Wielkość partii transferowej wynosi 5 sztuk.

3 Partia części licząca 200 sztuk jest przetwarzana w procesie produkcyjnym ruchem równoległo-sekwencyjnym. Proces obróbki części składa się z sześciu operacji, których czas trwania wynosi odpowiednio min: T 1 =8; T 2 =3; T 3 =27; T 4 =6; T 5 =4; T 6 = 20. Trzecią operację wykonujemy na trzech maszynach, szóstą na dwóch, a każdą z pozostałych operacji na jednej maszynie. Określ, jak zmieni się czas trwania cyklu przetwarzania partii części, jeśli równoległo-sekwencyjna wersja ruchu w produkcji zostanie zastąpiona równoległą. Wielkość partii transferowej wynosi 20 sztuk.

4 Partia części licząca 300 sztuk jest przetwarzana w procesie produkcyjnym ruchem równoległo-sekwencyjnym. Proces przetwarzania części składa się z siedmiu operacji, których czas trwania wynosi odpowiednio min: T 1 =4; T 2 =5; T 3 =7; T 4 =3; T 5 =4; T 6 =5; T 7 = 6. Każda operacja wykonywana jest na jednej maszynie. Partia transferowa – 30 sztuk. W wyniku udoskonalenia technologii produkcji czas trwania trzeciej operacji skrócił się o 3 minuty, siódmej o 2 minuty. Określ, jak zmienia się cykl przetwarzania partii części.

5 Podano partię półfabrykatów składającą się z 5 sztuk. Partia przechodzi 4 operacje: czas trwania pierwszej wynosi 10 minut, drugi 20 minut, trzeci 10 minut, czwarty 30 minut. Określ czas trwania cyklu metodami analitycznymi i graficznymi z ruchem sekwencyjnym.

6 Podano partię półfabrykatów składającą się z czterech sztuk. Partia przechodzi 4 operacje: czas trwania pierwszej wynosi 5 minut, drugi 10 minut, trzeci 5 minut, czwarty 15 minut. Określ czas trwania cyklu metodami analitycznymi i graficznymi z ruchem równoległym.

7 Podano partię półfabrykatów składającą się z 5 sztuk. Partia przechodzi 4 operacje: czas trwania pierwszej wynosi 10 minut, drugi 20 minut, trzeci 10 minut, czwarty 30 minut. Wyznaczanie czasu trwania cyklu metodami analitycznymi i graficznymi dla ruchu szeregowo-równoległego.

8 Określ czas trwania cyklu technologicznego przetwarzania partii produktów liczącej 180 sztuk. z równoległymi i sekwencyjnymi wariantami jego ruchu. Twórz wykresy procesów przetwarzania. Wielkość partii transferowej wynosi 30 sztuk. Standardy czasu i liczba stanowisk pracy w operacjach są następujące.

Wersja przełączana poprzedniego algorytmu jest algorytmem o najkrótszym pozostałym czasie wykonania. Zgodnie z tym algorytmem, planista za każdym razem wybiera proces z najkrótszym pozostałym czasem wykonania. W tym przypadku również konieczne jest wcześniejsze poznanie czasu realizacji zadania. Kiedy pojawia się nowe zadanie, jego całkowity czas wykonania jest porównywany z pozostałym czasem wykonania bieżącego zadania. Jeżeli czas realizacji nowego zadania będzie krótszy, bieżący proces zostanie zawieszony, a kontrola przeniesiona na nowe zadanie. Schemat ten umożliwia szybką obsługę krótkich żądań.

Planowanie trójpoziomowe

Systemy przetwarzania wsadowego umożliwiają planowanie trójpoziomowe, jak pokazano na rysunku. Gdy nowe zadania docierają do systemu, są najpierw umieszczane w kolejce przechowywanej na dysku. Wlot harmonogram dostępu wybiera zadanie i przekazuje je do systemu. Pozostałe zadania pozostają w kolejce.

Gdy tylko zadanie trafi do systemu, zostanie dla niego utworzony odpowiedni proces i może od razu rozpocząć rywalizację o dostęp do procesora. Może się jednak zdarzyć, że procesów będzie za dużo i wszystkie nie zmieszczą się w pamięci, wtedy część z nich zostanie stronicowana na dysk. Drugi poziom planowania określa, które procesy mogą być przechowywane w pamięci, a które na dysku. To jest to, co robi harmonogram pamięci .

Program planujący pamięć okresowo sprawdza procesy na dysku, aby zdecydować, które z nich przenieść do pamięci. Wśród kryteriów stosowanych przez planistę są następujące:

1. Ile czasu minęło od zamiany procesu na dysk lub załadowania go z dysku?

2. Jak długo proces korzysta z procesora?

3. Jaka jest wielkość procesu (małe procesy nie przeszkadzają)?

4. Jakie jest znaczenie tego procesu?

Trzeci poziom planowania odpowiada za umożliwienie procesom w stanie gotowości dostępu do procesora. Kiedy mówimy o „harmonogramie”, zwykle mamy na myśli Harmonogram procesora . Ten program planujący wykorzystuje dowolny algorytm odpowiedni do sytuacji, zarówno z przerwami, jak i bez nich. Przyjrzeliśmy się już niektórym z tych algorytmów, a inne poznamy później.

Planowanie w systemach interaktywnych.

Planowanie cykliczne.

Jednym z najstarszych, najprostszych, najuczciwszych i najczęściej używanych jest algorytm planowania cyklicznego. Każdemu procesowi przydzielana jest określona ilość czasu procesora, tzw. przedział czasu. Jeśli na koniec przedziału czasu proces nadal działa, zostaje zakończony, a kontrola zostaje przekazana innemu procesowi. Oczywiście, jeśli proces zostanie zablokowany lub zakończy się wcześniej, w tym momencie następuje przejście kontroli. Implementacja planowania okrężnego jest prosta. Harmonogram musi jedynie utrzymywać listę procesów w stanie gotowości. Kiedy proces osiągnie swój limit czasu, jest wysyłany na koniec listy.

Jedynym interesującym aspektem tego algorytmu jest długość kwantu. Przejście z jednego procesu do drugiego zajmuje trochę czasu - konieczne jest zapisanie i załadowanie rejestrów i map pamięci, aktualizacja tabel i list, zapisanie i ponowne załadowanie pamięci podręcznej itp. Wniosek można sformułować następująco: zbyt mały kwant doprowadzi na częste przełączanie procesów i małą wydajność, ale zbyt duża może skutkować powolną reakcją na krótkie żądania interaktywne. Wartość kwantowa wynosząca około 2 0–5 0 ms jest często rozsądnym kompromisem.

Planowanie priorytetowe.

Planowanie okrężne opiera się na ważnym założeniu, że wszystkie procesy są równe. W sytuacji komputera z dużą liczbą użytkowników może to nie mieć miejsca. Na przykład na uniwersytecie najpierw należy obsłużyć dziekanów, potem profesorów, sekretarki, sprzątaczki, a dopiero potem studentów. Konieczność uwzględnienia takich czynników zewnętrznych prowadzi do planowania priorytetowego. Podstawowa idea jest prosta: każdemu procesowi przypisany jest priorytet, a kontrola przekazywana jest gotowemu procesowi o najwyższym priorytecie.

Kilka kolejek.

W systemie CTSS (kompatybilny system podziału czasu) zaimplementowano jeden z harmonogramów pierwszego priorytetu.Głównym problemem systemu CTSS było zbyt wolne przełączanie procesów, ponieważ komputer IBM 7094 mógł przechowywać w pamięci tylko jeden proces. Każdy przełącznik oznaczał przeniesienie bieżącego procesu na dysk

i odczytanie nowego procesu z dysku. Twórcy CTSS szybko zdali sobie sprawę, że wydajność byłaby większa, gdyby procesom ograniczonym przez procesor przydzielono większy przedział czasu, niż gdyby przydzielono im mniejsze wycinki czasu, ale często. Z jednej strony zmniejszy to liczbę transferów z pamięci na dysk, z drugiej strony doprowadzi do pogorszenia czasu odpowiedzi, jak już widzieliśmy.

W rezultacie opracowano rozwiązanie z klasami priorytetów. Procesom o najwyższym priorytecie przydzielono jeden kwant, procesom w następnej klasie przydzielono dwa kwanty, procesom w następnej klasie przydzielono cztery kwanty itd. Gdy proces wykorzystał cały przydzielony mu czas, był przenoszony do niższego poziomu klasa.

Jako przykład rozważmy proces, który musi obliczyć ponad 100 kwantów. Najpierw otrzyma jeden kwant, następnie zostanie przepompowany na dysk. Następnym razem dostanie 2 kwanty, potem 4, 8,16, 32, 64, chociaż z 64 wykorzystuje tylko 37. W tym przypadku potrzebnych będzie tylko 7 transferów (wliczając ładunek początkowy) zamiast 100, które byłyby potrzebne przy użyciu algorytmu okrężnego. Dodatkowo w miarę zagłębiania się w kolejkę priorytetową proces będzie uruchamiany coraz rzadziej, oddając procesor krótszym procesom.

„Najkrótszy proces to następny”

Ponieważ algorytm Shortest Task First minimalizuje średni czas realizacji w systemach przetwarzania wsadowego, chciałoby się go stosować także w systemach interaktywnych. W pewnym stopniu jest to możliwe. Procesy interaktywne najczęściej przebiegają według schematu „czekanie na polecenie, wykonanie polecenia, oczekiwanie na polecenie, wykonanie polecenia…” Jeśli potraktujesz wykonanie każdego polecenia jako osobne zadanie, możesz zminimalizować ogólną średnią odpowiedź czas, uruchamiając najpierw najkrótsze zadanie. Jedynym problemem jest to

jest zrozumienie, który z procesów oczekiwania jest najkrótszy.

Jedna z metod opiera się na szacowaniu długości procesu na podstawie poprzedniego zachowania procesu. W tym przypadku uruchamiany jest proces o najkrótszym przewidywanym czasie. Załóżmy, że oczekiwany czas wykonania polecenia wynosi T 0, a oczekiwany czas następnego wykonania wynosi T 1 . Można poprawić oszacowanie czasu, biorąc sumę ważoną tych czasów aT 0 + (1 - a)T 1 . Wybierając odpowiednią wartość a, możemy sprawić, że algorytm estymacji szybko zapomni o poprzednich przebiegach lub odwrotnie, zapamięta je na długo. Przyjmując a = 1/2, otrzymujemy serię szacunków:

T 0, T 0/2 + T 1/2, T 0/4 + T 1/4 + T 2/2, T 0/8 + T 1/8 + T 2/4 + T 3/2.

Po trzech seriach waga T 0 w estymacji spadnie do 1/8.

Metodę szacowania kolejnej wartości w serii za pomocą średniej ważonej poprzedniej wartości i poprzedniego oszacowania często nazywa się starzeniem. Metoda ta ma zastosowanie w wielu sytuacjach, gdzie konieczne jest oszacowanie na podstawie poprzednich wartości. Najprostszym sposobem wdrożenia starzenia jest a = 1/2. Na każdym kroku po prostu potrzebujesz

dodaj nową wartość do aktualnego oszacowania i podziel sumę na pół (przesuwając w prawo o 1 bit).

Gwarancja planowania.

Zupełnie inne podejście do planowania polega na składaniu użytkownikom prawdziwych obietnic, a następnie ich realizowaniu. Oto jedna obietnica, którą łatwo powiedzieć i łatwo dotrzymać: jeśli udostępnisz procesor n użytkownikom, otrzymasz 1/n mocy procesora.

W systemie z jednym użytkownikiem i n procesorami każdy otrzyma 1/n cykli procesora.

Aby spełnić tę obietnicę, system musi śledzić alokację procesora pomiędzy procesami od momentu utworzenia każdego procesu. Następnie system oblicza ilość zasobów procesora, do których uprawniony jest proces, na przykład czas od utworzenia podzielony przez n. Teraz możemy obliczyć stosunek czasu poświęconego procesowi do czasu, jaki mu przysługuje. Otrzymana wartość 0,5 oznacza, że ​​proces otrzymał tylko połowę przyznanej mu kwoty, a 2,0 oznacza, że ​​proces otrzymał dwukrotnie więcej niż miał. Następnie rozpoczyna się proces z najmniejszym stosunkiem, aż do

nie stanie się większy od swojego najbliższego sąsiada.

Planowanie loterii.

Algorytm opiera się na rozdzielaniu losów loteryjnych pomiędzy procesy w celu uzyskania dostępu do różnych zasobów, w tym procesora. Kiedy planista musi podjąć decyzję, los na loterię jest wybierany losowo, a jego właściciel uzyskuje dostęp do zasobu. Jeśli chodzi o dostęp do procesora, „loteria” może zdarzyć się 50 razy na sekundę, a zwycięzca otrzyma 20 ms czasu procesora.

Ważniejszym procesom można przypisać dodatkowe bilety, aby zwiększyć prawdopodobieństwo wygranej. Jeśli jest tylko 100 biletów i 20 z nich jest w jednym procesie, to otrzyma 20% czasu procesora. W przeciwieństwie do harmonogramu priorytetów, w którym bardzo trudno jest ocenić, co oznacza, powiedzmy, priorytet 40, w harmonogramie loterii wszystko jest oczywiste. Każdy proces otrzyma procent zasobów w przybliżeniu równy procentowi posiadanych biletów.

Planowanie loterii ma kilka interesujących właściwości. Przykładowo, jeśli podczas tworzenia proces otrzyma kilka losów, to w następnej loterii jego szanse na wygraną są proporcjonalne do liczby losów.

W razie potrzeby procesy komunikujące się mogą wymieniać bilety. Tak więc, jeśli proces klienta wysyła komunikat do procesu serwera, a następnie blokuje, może przekazać wszystkie swoje bilety do procesu serwera, aby zwiększyć szansę na uruchomienie serwera. Po zakończeniu procesu serwera może zwrócić wszystkie bilety z powrotem.

Uczciwe planowanie.

Do tej pory zakładaliśmy, że każdy proces jest kontrolowany niezależnie od tego, kto jest jego właścicielem. Zatem jeśli użytkownik 1 utworzy 9 procesów, a użytkownik 2 - 1 proces, to stosując planowanie okrężne lub w przypadku równych priorytetów, użytkownik 1 otrzyma 90% procesora, a użytkownik 2 tylko 10.

Aby uniknąć takich sytuacji, niektóre systemy zwracają uwagę na właściciela procesu przed zaplanowaniem. W tym modelu każdy użytkownik otrzymuje określoną część procesora, a planista wybiera proces zgodnie z tym faktem. Jeśli w naszym przykładzie każdy użytkownik miał

obiecali 50% procesora, to dostaną 50% procesora, niezależnie od liczby procesów.

Planowanie w systemach czasu rzeczywistego.

W systemach czasu rzeczywistego czas odgrywa kluczową rolę. Najczęściej jedno lub więcej zewnętrznych urządzeń fizycznych generuje sygnały wejściowe, a komputer musi na nie odpowiednio zareagować w określonym przedziale czasu.

Systemy czasu rzeczywistego dzielą się na twarde systemy czasu rzeczywistego , co oznacza obecność ścisłych terminów wykonania każdego zadania (należy ich dotrzymać) oraz elastyczne systemy czasu rzeczywistego , w którym naruszenia harmonogramu są niepożądane, ale dopuszczalne. W obu przypadkach program jest podzielony na kilka procesów, z których każdy jest przewidywalny. Procesy te są najczęściej krótkie i kończą się w ciągu sekundy. Gdy pojawi się sygnał zewnętrzny, to planista musi zadbać o dotrzymanie harmonogramu.

Zdarzenia zewnętrzne, na które system musi zareagować, można podzielić na okresowy(występujące w regularnych odstępach czasu) i nieokresowe(występujące w sposób nieprzewidywalny). Może istnieć kilka okresowych strumieni zdarzeń, które system musi przetworzyć. W zależności od czasu potrzebnego na przetworzenie każdego zdarzenia, system może nie być w stanie przetworzyć wszystkich zdarzeń w odpowiednim czasie.

Powiązana informacja.

Wszystko, co zostało opisane w kilku poprzednich rozdziałach, było bardziej zorientowane na dalsze badania nad problemem czasu własnego procesu, a w znacznie mniejszym stopniu na zastosowania praktyczne. Wypełniając tę ​​lukę, przedstawimy jeden ze sposobów obliczania prawidłowego czasu procesu w oparciu o dane statystyczne dotyczące jego ewolucji.

Rozważmy proces jednowymiarowy, którego stan charakteryzuje się zmienną rzeczywistą x. Załóżmy, że obserwacje dynamiki procesu prowadzone są w astronomicznym czasie t, tak że t = t k i x = x k, k =1, ..., n są stałymi momentami obserwacji i odpowiadającymi im wartościami stany procesu. Istnieje wiele różnych metod matematycznych, które umożliwiają konstruowanie krzywych albo przechodzących przez punkty (t k, Xk), albo „najlepszego podejścia” do nich. Otrzymane w ten sposób funkcje x = x(t) budzą w nas wrażenie, że rozpatrywany proces zależy od mechanicznego ruchu ciał niebieskich i dlatego jego stan wyraża się poprzez czas astronomiczny t. Wniosek ten można wziąć pod uwagę; gdyby nie pojawiały się ciągłe trudności przy próbie przewidzenia dalszego przebiegu procesu. Dla dużej liczby różnych procesów, które nie są bezpośrednio związane z ruchami mechanicznymi ciał niebieskich, przewidywania teoretyczne uzyskane za pomocą funkcji x = x(t) poza przedziałem obserwacyjnym zaczynają znacząco odbiegać od kolejnych danych eksperymentalnych. Zwykle starają się wyjaśnić przyczynę rozbieżności między teorią a eksperymentem nieudanie dobraną metodą przetwarzania, ale może nie w tym leży istota sprawy.

Każdy proces, który nas interesuje, zachodzi we Wszechświecie. Z pewnością „czuje” wpływ ruchu ciał niebieskich. Wpływ ten może jednak okazać się „niesztywny”, niedeterminujący. Może to objawiać się w szczególności tym, że w pewnych odstępach czasu astronomicznego stan procesu pozostaje niezmieniony. Przypomnijmy w związku z tym wcześniejszy przykład zamkniętego, pustego pokoju, odizolowanego od świata zewnętrznego. Pozwólmy choć jednemu żywemu wlecieć do pokoju. W ciągu kilku dni zmiany stanu systemu „mucha” będą zależeć od ruchów muchy, ponieważ nie można oczekiwać zmian w stanie pokoju. Jednocześnie trudno sobie wyobrazić, że zachowanie muchy jest ściśle powiązane z biegiem czasu astronomicznego.

Po tak długiej dygresji przejdźmy do opisu algorytmu obliczania czasu własnego procesu.

W algorytmie tym jako naturalną miarę czasu wybiera się jednostkę obliczania maksimów lokalnych. Dodatkowo brane są pod uwagę możliwe odcinki stanu stacjonarnego procesu, w których, jak zauważono wcześniej, zatrzymuje się czas właściwy. Ponieważ identyczność dwóch stanów można stwierdzić jedynie w granicach dokładności pomiaru, w dalszej części stosuje się pewną liczbę dodatnią e – dopuszczalny błąd pomiaru.

Zatem danymi wejściowymi algorytmu jest liczba naturalna n, liczba dodatnia 8, tablice (tk) i (x k), k = 1, ..., n. Dla ułatwienia programowania algorytm przedstawiono w postaci z czterech sekwencyjnie realizowanych modułów.

Moduł 1, korzystając z danych p, e, t k), (x k), w ogólnym przypadku tworzy nowe tablice 7 = (7+ X = (X t) i bardzo specyficzną towarzyszącą tablicę P = (?), gdzie 1 = 1, ..., t i t<Сп. Основное назначение этого модуля -- выявление в массиве x k) последовательностей идентичных состояний процесса, сохранение первых элементов в таких последовательностях и удаление всех остальных и, наконец, уменьшение по определенному, правилу исходного интервала наблюдения от t до на сумму тех промежутков времени, в которых процесс протекает стационарно.

Moduł 1 obejmuje następujące procedury:

p: = 1, t: = 0, k: = 1.

na s. Wprowadzono 1, 2 liczniki z określonymi wartościami początkowymi:

na s. 3, 4 wartości licznika zwiększają się o 1.

Sprawdź warunek k^n. Jeśli jest zakończony, przejdź do kroku 6, w przeciwnym razie przejdź do kroku 11.

Sprawdź nierówność x k --x k = e. Jeśli zachodzi, przejdź do kroku 7, w przeciwnym razie przejdź do kroku 9.

7. tii = ti - (tkl - tk), i = k1, ..., str.

Procedura ta oznacza, że ​​jeśli wartości Xk i Xk 1 są w obrębie błędu nierozróżnialne, to wszystkie punkty czasowe rozpoczynające się od tk są zmniejszane o wielkość tki-tk.

r = r. Wróć do punktu 4.

telewizor = t k; X v:=x k ; p = p v = v+l., tj. Tworzone są elementy tablic T, X, P i przypisywana jest kolejna wartość v.

• 10. Przyjmij (t k, ..., t n AND (Xk, - X n) jako początkowe tablice wymiaru n--k 1 + 1, a następnie wróć do kroku 2.
• 11. Wydrukuj m, (T), (X,) i (P,), gdzie i = l, ..., t. Koniec.

Wyjaśnijmy znaczenie elementów towarzyszącej tablicy P. Z poprzedniego tekstu wynika, że ​​wartość pk jest równa liczbie tych elementów tablicy (xk), które bezpośrednio następują i różnią się od x pi+... +, + o mniej niż e. Zauważamy również, że pi+ ... +p m = n.

Przykład 1. Dane: n = 20, (/*) = (2, 4, 7, 10, 12, 13, 15, 17, 20, 22, 24, 25,

• 27, 30, 32, 33, 34, 35, 36) i (x,)= (4, 4, 6, 6, 6, 3, 2, 4, 3, 3, 3, 2, 2, 4, 5 , 5,
• 5, 4, 3), patrz ryc. 9, o.

W wyniku wykonania modułu 1 otrzymuje się m = 11,

(G) = (2, 3, 4, 6, 8, 11, 1-2, 15, 17, 18, 19); (X,) = (4, 6, 3, 2, 4, 3, 2, 4,5,4,3)

i(d.) = (2, 4, 1, 1, 1,3, 2, 1,3, 1, 1), patrz ryc. 9, ur.

Moduł 2. Danymi wejściowymi dla niego jest liczba naturalna m, a także tablice (7+ (X L), = 1, ..., m. Moduł ten w tablicy (TJ identyfikuje momenty czasu [TM a], 1 = 1 m (ml

Przykład 2. Wartości m, (Ть) i (X,] są zapożyczone z poprzedniego przykładu. Po ukończeniu modułu 2 otrzymujemy ml = 3, m2 = 8, (Ш,) = (3, 8, 17 ), (Т*) = (3, 4, 6, 8, 11, 12, 15, 17), patrz także ryc. 9, b.

Moduł 3. Dane wejściowe ml, m2, (TM n), 1 = 1, ..., ml, (G*), /2 = 1, ..., gn2.

Moduł ten przeznaczony jest do konstruowania tablicy (t(-r) przy użyciu wzoru

Gdzie jest TV 6 [TMp, TMn+i]

Zmienna t jest czasem właściwym wygenerowanym przez zmianę zmiennej x. Jego naturalną miarą jest jednostka obliczania lokalnych maksimów.

Przykład 3. Początkowe dane dla T 2) są takie same jak wartości ml, m2 ITM i w przykładzie 2. . Po odpowiednich obliczeniach otrzymujemy Н = (0; 0,2; 0,6; 1; 1,33; 1,78; 2).

Moduł 4. Generuje wynik poprzez ustalenie zgodności pomiędzy wartościami m i elementami x z tablicy (xk).

Przykład 4. Na podstawie danych z przykładów 2 i 3 uzyskano następujący wynik, patrz ryc. 9, w:

t: 0; 0,2; 0,6; 1; 1,33; 1,44;

x: 6; 3; 2; 4; 3T 0 2;

Zatem rozpatrywany algorytm pozwala na opracowanie koncepcji czasu własnego procesu w oparciu o informacje o zmianach stanu procesu zarejestrowane w astronomicznej skali czasu. Oczywiste jest, że można zastosować inne algorytmy, bazujące np. na obliczaniu ciągu lokalnych minimów lub ciągu mieszanego składającego się z lokalnych maksimów i minimów. Podczas przetwarzania danych eksperymentalnych prawdopodobnie należy przetestować różne opcje. Jeżeli z jakiegoś powodu eksperymentator wybrał jeden z określonych czasów właściwych i otrzymał tablice (t4 i (xk), to w kolejnym etapie powinien zastosować pewne metody matematyczne w celu przybliżenia punktów eksperymentalnych (t*, x) jakiejś przybliżonej linii świata proces x = x(t) Ekstrapolując tę ​​prostą poza początkowy okres obserwacji, można przewidzieć dalszy przebieg procesu.

Warto wspomnieć o eksperymencie obliczeniowym mającym na celu ocenę możliwości zastosowania zaproponowanego algorytmu. Jako materiał doświadczalny wybrano dane dotyczące rocznych przepływów rzek. Wachsz (Tadżykistan) przez ostatnie 40 lat. W tym samym okresie zebrano informacje o dynamice liczby Wolfa – najczęściej stosowanego całkowego wskaźnika aktywności Słońca. To ostatnie stanowiło podstawę do ustalenia prawidłowego czasu procesu aktywności Słońca. Do czasów współczesnych informacje o wydatkach na rzekach uległy przekształceniu. Wachsza, a następnie w okresie obserwacji podano teoretyczną zależność przepływu wody w funkcji właściwego czasu aktywności słonecznej. Cechą charakterystyczną powstałego wykresu jest niemal okresowe zachowanie wydatków maksymalnych i minimalnych. Koszty nie są jednak stałe.