Algoritmus pro výpočet správné doby procesu. Plánování (výpočetní technika) Technický ředitel Centra pro inovativní technologie a řešení „Jet Infosystems“


Úvod

Účelem workshopu organizace výroby je rozšířit a prohloubit teoretické znalosti, vštípit potřebné dovednosti k řešení nejčastějších problémů v praxi na organizaci a plánování výroby.

Workshop obsahuje úkoly pro hlavní části kurzu. Na začátku každého tématu jsou uvedeny stručné metodické pokyny a teoretické informace, typické úlohy s řešením a úlohy k samostatnému řešení.

Přítomnost metodických pokynů a stručných teoretických informací ke každému tématu umožňuje využít tento workshop v korespondenčních kurzech.


Výpočet doby trvání výrobního cyklu

Jako ukazatel efektivity produkční proces je doba trvání výrobního cyklu.

Výrobní cyklus- doba setrvání pracovních předmětů ve výrobním procesu od okamžiku uvedení surovin na trh do okamžiku uvolnění hotového výrobku.

Výrobní cyklus se skládá z pracovní čas, při které se vynakládá práce, a přestávky... Přestávky lze v závislosti na důvodech, které je způsobily, dále rozdělit:

1) zapnuto přírodní nebo technologické – jsou dány povahou produktu;

2) organizační(přestávky mezi směnami).

Délka výrobního cyklu se skládá z následujících složek:

Cyklus T = t ty + t jíst + t tr + t k.k. + t m. o. + t m.ts.

kde t ty- doba technologických operací;

t jí - doba přírodních procesů (sušení, chlazení atd.);

t tr - doba přepravy pracovních předmětů;

t c.c. -čas kontroly kvality;

t m.o - mezioperační doba lůžka;

t m.ts. -čas strávený v meziresortních skladech;

(t tři t k.k. lze kombinovat s t m.o).

Výpočet doby trvání výrobního cyklu závisí na typu výroby. V hromadné výrobě je délka výrobního cyklu určena dobou, po kterou je produkt na toku, tzn.

Cyklus T = t v M,

kde t proti- cyklus uvolňování;

M- počet pracovišť.

Pod takt uvolnění měl by být chápán časový interval mezi uvolněním jednoho vyrobeného produktu a dalšího produktu.

Cyklus uvolňování je určen vzorcem

t in = Teff / V,

kde Teff- efektivní fond času pracovníka za zúčtovací období (směna, den, rok);

PROTI- objem produkce za stejné období (v naturálních jednotkách).

Příklad: T cm = 8 hodin = 480 min; T pruh = 30 min; → Teff = 480 - - 30 = 450 min.

B = 225 ks; → t h = 450/225 = 2 min.

PROTI sériová výroba pokud se zpracování provádí po dávkách, délka technologického cyklu se nestanoví na jednotku výroby, ale na celou dávku. Navíc v závislosti na způsobu uvedení šarže do výroby dostáváme různé doby cyklu. Existují tři způsoby přesunu produktů ve výrobě: sekvenční, paralelní a smíšené (sériově-paralelní).


... Na konzistentní pohyblivých částí, každá následující operace začíná až poté, co skončí předchozí. Doba cyklu pro sekvenční pohyb součástí se bude rovnat:

kde n - počet dílů zpracovávané dávky;

t ksi- kusová rychlost operace;

C i- počet pracovních míst na i operace;

m- počet operací technologického procesu.

Je dána dávka 5 položek. Dávka prochází postupně 4 operacemi; doba trvání první operace - 10 minut, druhá - 20 minut, třetí - 10 minut, čtvrtá - 30 minut (obr. 1).

Obrázek 1

T cyklus = T poslední = 5 (10 + 20 + 10 + 30) = 350 min.

Sekvenční způsob pohybu dílů má tu výhodu, že umožňuje provoz zařízení bez prostojů. Jeho nevýhodou však je, že délka výrobního cyklu je v tomto případě největší. Na pracovištích navíc vznikají značné zásoby dílů, což vyžaduje další výrobní prostory.

II... Na paralelní při pohybu dávky se jednotlivé díly na pracovištích nezdržují, ale individuálně převádějí do další operace ihned, bez čekání na dokončení zpracování celé dávky. Při paralelním pohybu dávky dílů na každém pracovišti jsou tedy současně prováděny různé operace na různých dílech téže dávky.

Trvání dávkového zpracování s paralelním pohybem produktů je výrazně sníženo:

dl .

kde n n- počet dílů v přenosová dávka(přepravní zásilka), tzn. počet produktů současně převedených z jedné operace do druhé;

Dl - nejdelší pracovní cyklus.

Při paralelním náběhu šarže výrobků se části celé šarže zpracovávají průběžně pouze na těch pracovištích, kde dlouhé operace navazují na krátké. V případech, kdy krátké operace následují po dlouhých, tzn. déle (v našem příkladu - třetí operace), provádění těchto operací se provádí přerušovaně, tzn. nečinné zařízení. Zde nelze dávku dílů zpracovat okamžitě, bez zpoždění, protože předchozí (dlouhá) operace to neumožňuje.

V našem příkladu: n= 5, t 1 = 10; t 2 = 20; t 3 = 10; t 4 = 30; S= 1.

T pára = 1 (10 + 20 + 10 + 30) + (5-1) 30 = 70 + 120 = 190 min.

Uvažujme schéma paralelního pohybu dílů (obr. 2):

Obrázek 2

III... Pro eliminaci přerušení zpracování jednotlivých částí dávky ve všech operacích aplikujte paralelně-sériový nebo smíšený způsob spouštění, při kterém jsou díly (po jejich zpracování) převáděny do další operace jedna po druhé, nebo formou „přepravních“ nedodělků (více kusů najednou) tak, že provádění operací je nepřerušena na žádném pracovišti. U smíšeného způsobu je kontinuita zpracování převzata ze sekvenčního způsobu a z paralelního způsobu přechod dílu z provozu do provozu ihned po jeho zpracování. Při smíšeném způsobu uvedení do výroby je doba cyklu určena vzorcem

kor .

kde kor. - nejkratší pracovní cyklus (z každé dvojice sousedních operací);

m-1 počet zarovnání.

Pokud je následující operace delší než předchozí nebo se jí rovná v čase, pak se tato operace spouští jedna po druhé, ihned po zpracování první části v předchozí operaci. Pokud je naopak následná operace kratší než ta předchozí, dochází k mezerám v přenosu kus po kusu. K jejich předcházení je nutné naakumulovat přepravní rezervu takového objemu, který postačuje k zajištění práce v následném provozu. Pro praktické nalezení tohoto bodu na grafu je nutné přenést poslední detail dávky a posunout dobu jejího provedení doprava. Doba zpracování pro všechny ostatní části dávky je vynesena doleva v grafu. Začátek zpracování první části ukazuje okamžik, kdy má být přepravní rezerva z předchozí operace převedena na tuto operaci.

Pokud mají sousední operace stejnou dobu trvání, je akceptována pouze jedna z nich jako krátká nebo dlouhá (obr. 3).

Obrázek 3

T poslední pára = 5 (10 + 20 + 10 + 30) - (5-1) (10 + 10 + 10) = 350-120 = 230 min.

Hlavní způsoby, jak zkrátit dobu trvání výrobního cyklu, jsou:

1) Snížení pracnosti výroby výrobků zlepšením vyrobitelnosti vyráběné konstrukce, využití počítačů, zavádění pokročilých technologických postupů.

2) Racionální organizace pracovní procesy, uspořádání a údržba pracovišť na základě specializace a kooperace, rozsáhlá mechanizace a automatizace výroby.

3) Omezení různých plánovaných i neplánovaných přerušení práce na základě racionálního využití zásad vědecká organizace produkční proces.

4) Zrychlení průběhu reakcí v důsledku zvýšení tlaku, teplot, přechodu na kontinuální proces atd.

5) Zlepšení procesů dopravy, skladování a kontroly a jejich časové překrývání s procesem zpracování a montáže.

Zkrácení délky výrobního cyklu je jedním z vážných úkolů organizace výroby, protože ovlivňuje obrat pracovní kapitál, snížení mzdových nákladů, snížení skladovacích prostor, potřeba dopravy atp.

Úkoly

1 Určete dobu trvání cyklu zpracování 50 dílů v sekvenčním, paralelním a sekvenčně-paralelním typu pohybu ve výrobním procesu. Zpracování dílů se skládá z pěti operací, jejichž doba trvání je min: t 1 =2; t 2 =3; t 3 =4; t 4 =1; t 5 = 3. Druhá operace se provádí na dvou strojích a každý z ostatních na jednom. Velikost přenosové dávky je 4 kusy.

2 Určete dobu trvání cyklu zpracování 50 dílů se sekvenčním, paralelním a sekvenčně-paralelním typem pohybu ve výrobním procesu. Zpracování dílů se skládá ze čtyř operací, jejichž doba trvání je min: t 1 =1; t 2 =4; t 3 =2; t 4 = 6. Čtvrtá operace se provádí na dvou strojích a každý z ostatních na jednom. Velikost přenosové dávky je 5 kusů.

3 Dávka dílů 200 kusů je zpracována s paralelně sekvenčním pohybem ve výrobním procesu. Zpracování dílů se skládá ze šesti operací, jejichž doba trvání je min: t 1 =8; t 2 =3; t 3 =27; t 4 =6; t 5 =4; t 6 = 20. Třetí operace se provádí na třech strojích, šestá na dvou a každá z dalších operací se provádí na jednom stroji. Určete, jak se změní doba cyklu zpracování pro dávku dílů, pokud se paralelně-sekvenční varianta pohybu ve výrobě nahradí paralelní. Velikost přenosové dávky je 20 kusů.

4 Dávka 300 kusů je zpracována s paralelně sekvenčním pohybem ve výrobním procesu. Zpracování dílů se skládá ze sedmi operací, jejichž doba trvání je min: t 1 =4; t 2 =5; t 3 =7; t 4 =3; t 5 =4; t 6 =5; t 7 = 6. Každá operace se provádí na jednom stroji. Přenosová dávka - 30 kusů. V důsledku vylepšené výrobní technologie se doba třetí operace zkrátila o 3 minuty, sedmá - o 2 minuty. Určete, jak se změní dávkový cyklus.

5 Je dána šarže polotovarů skládající se z 5 kusů. Dávka prochází 4 operacemi: délka první je 10 minut, druhá 20 minut, třetí 10 minut a čtvrtá 30 minut. Určete dobu trvání cyklu pomocí analytických a grafických metod pro sekvenční pohyb.

6 Je dána šarže polotovarů sestávající ze čtyř kusů. Dávka prochází 4 operacemi: doba trvání první je 5 minut, druhá 10 minut, třetí 5 minut a čtvrtá 15 minut. Analyticky a graficky určete dobu cyklu s paralelním pohybem.

7 Je dána šarže polotovarů skládající se z 5 kusů. Dávka prochází 4 operacemi: délka první je 10 minut, druhá 20 minut, třetí 10 minut a čtvrtá 30 minut. Určete dobu trvání cyklu pomocí analytických a grafických metod pro sekvenční-paralelní pohyb.

8 Určete dobu trvání technologického cyklu zpracování dávky 180 kusů. s paralelními a sekvenčními verzemi jeho pohybu. Vytvářejte grafy zpracování. Velikost přenosové dávky - 30 ks. Normy času a počtu pracovních míst v provozech jsou následující.

Vše, co bylo popsáno v několika předchozích částech, bylo zaměřeno spíše na provedení dalšího výzkumu problému vnitřního procesního času a v mnohem menší míře na praktické aplikace. Abychom tuto mezeru zaplnili, nastíníme jeden ze způsobů, jak vypočítat správný čas procesu na základě statistických údajů o jeho vývoji.

Uvažujme jednorozměrný proces, jehož stav je charakterizován reálnou proměnnou x. Předpokládejme, že pozorování dynamiky procesu se provádí v astronomickém čase t, takže t = tk a x = xk, k = 1, ..., n jsou pevné časy pozorování a odpovídající hodnoty stavů proces. Existuje mnoho různých matematických metod, které umožňují konstruovat křivky, které buď procházejí body (t k, Xk), nebo se k nim přibližují „nejlepším způsobem“. Výsledné funkce x = x (t) v naší mysli vyvolávají dojem, že uvažovaný proces závisí na mechanickém pohybu nebeských těles, a proto je jeho stav vyjádřen astronomickým časem t. S takovým závěrem by se dalo počítat; kdyby nebyly neustálé potíže ve snaze předvídat další průběh procesu. Pro velké množství různých procesů, které přímo nesouvisejí s mechanickými pohyby nebeských těles, se teoretické předpovědi získané pomocí funkce x = x (t) mimo interval pozorování začínají výrazně odchylovat od následných experimentálních dat. Důvod nesouladu mezi teorií a experimentem se obvykle snaží vysvětlit neúspěšně zvolenou metodou zpracování, ale podstata věci v tom být nemusí.

Jakýkoli proces, který nás zajímá, se odehrává ve Vesmíru. Ten samozřejmě „cítí“ dopad pohybu nebeských těles. Tento dopad však může být „nerigidní“, nedeterministický. To se může projevit zejména tím, že v určitých intervalech toku astronomického času zůstává stav procesu nezměněn. Vzpomeňme v této souvislosti na dříve uvedený příklad s uzavřenou prázdnou místností izolovanou od vnějšího světa. Nechme do místnosti vletět jen jednoho živého. Během několika dnů budou změny stavu systému house-fly záviset na pohybu mouchy, protože nelze očekávat změny ve stavu domu. Těžko si přitom představit, že chování mouchy je pevně spjato s průběhem astronomického času.

Po takové dlouhé odbočce přejděme k popisu algoritmu pro výpočet správného času procesu.

V tomto algoritmu je jednotka výpočtu lokálních maxim zvolena jako přirozená míra času. Kromě toho se berou v úvahu možné úseky stacionárního stavu procesu, ve kterých, jak již bylo uvedeno výše, se správný čas zastaví. Protože o identitě dvou stavů lze hovořit pouze v mezích přesnosti měření, použije se v budoucnu nějaké kladné číslo e - dovolená chyba měření.

Vstupními daty pro algoritmus jsou tedy přirozené číslo n, kladné číslo 8, pole (tk) a (xk), k = 1, ..., n. Pro usnadnění programování je algoritmus uveden v ve formě čtyř sekvenčně prováděných modulů.

modul 1, pomocí dat n, e, tk), (xk), v obecném případě tvoří nová pole 7 = (7+ X = (X t) a velmi specifické doprovodné pole P = (?), kde 1 = 1, . .., t, a t<Сп. Основное назначение этого модуля -- выявление в массиве x k) последовательностей идентичных состояний процесса, сохранение первых элементов в таких последовательностях и удаление всех остальных и, наконец, уменьшение по определенному, правилу исходного интервала наблюдения от t до на сумму тех промежутков времени, в которых процесс протекает стационарно.

Modul 1 obsahuje následující postupy:

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

V p.p. 1, 2 jsou zavedeny čítače se specifickými počátečními hodnotami:

V p.p. 3, 4, hodnoty počítadla se zvýší o 1.

Zkontrolujte stav k ^ n. Pokud je splněno, přejděte k bodu 6, jinak přejděte k bodu 11.

Zkontrolujte nerovnost x k --x k = e. Pokud platí, přejděte k položce 7, v opačném případě přejděte k položce 9.

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

Tento postup znamená, že pokud jsou hodnoty Xk a Xk 1 v rámci chyby nerozlišitelné, pak se všechny časy, počínaje tk, snižují o hodnotu tki-tk.

p = p. Návrat k bodu 4.

Tv = t k; Xv: = x k; p = p v = v + l., tzn. vytvoří se prvky polí T, X, P a přiřadí se další hodnota v.

  • 10. Vezměte (t k, ..., t n AND (Xk, - X n) jako počáteční pole dimenze n - k 1 + 1 a poté se vraťte k bodu 2.
  • 11. Vytiskněte m, (T), (X,) a (P,), kde i = l, ..., m. Konec.

Vysvětlíme si význam prvků doprovodného pole P. Z předchozího textu vyplývá, že hodnota pk je rovna počtu těch prvků pole (xk), které bezprostředně následují a liší se od x pi + . .. +, +, o méně než e. Všimněte si také, že pi + ... + pm = n.

Příklad 1. Je dáno: n = 20, (/ *) = (2, 4, 7, 10, 12, 13, 15, 17, 20, 22, 24, 25,

  • 27, 30, 32, 33, 34, 35, 36) a (x,) = (4, 4, 6, 6, 6, 3, 2, 4, 3, 3, 3, 2, 2, 4, 5 , 5,
  • 5, 4, 3), viz obr. 9, a.

Jako výsledek modulu 1 dostaneme m = 11,

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

a (d.) = (2, 4, 1, 1, 1,3, 2, 1,3, 1, 1), viz Obr. 9, b.

Modul 2 Vstupními daty pro něj jsou přirozené číslo m a také pole (7+ (XL), = 1, ..., t. Tento modul v poli (TJ prozrazuje časové okamžiky [TM a], 1 = 1 m (ml

Příklad 2. Hodnoty m, (T b) a (X,] jsou vypůjčeny z předchozího příkladu. Po provedení modulu 2 dostaneme ml = 3, m2 = 8, (U,) = (3, 8, 17), (T *) = (3, 4, 6, 8, 11, 12, 15, 17), viz také obr. 9, b.

Modul 3 Vstupní údaje ml, m2, (TM n), 1 = 1, ..., ml, (T *), / 2 = 1, ..., rn2.

Tento modul je navržen tak, aby sestavil pole (m (-g) podle vzorce

Kde TV 6 [TMp, TMn + i]

Proměnná m je její vlastní čas generovaný změnou proměnné x. Jeho přirozenou mírou je místní maximální jednotka.

Příklad 3. Počáteční data pro Т 2) jsou stejná jako hodnoty v ml, m2 ITM a v příkladu 2.. Po příslušných výpočtech dostaneme N = (0; 0,2; 0,6; 1; 1,33; 1,78; 2).

Modul 4. Tvaruje výstup výsledků stanovením korespondence mezi hodnotami m a prvky x z pole (xk).

Příklad 4. Na základě údajů z příkladů 2 a 3 se získá následující výsledek, viz Obr. 9, v:

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

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

Uvažovaný algoritmus tak umožňuje vyvinout koncept správného času procesu na základě informace o změně stavu procesu zaznamenané na astronomické časové škále. Je zcela jasné, že lze použít i jiné algoritmy založené například na výpočtu posloupnosti lokálních minim nebo smíšené posloupnosti skládající se z lokálních maxim a minim. Při zpracování experimentálních dat byste pravděpodobně měli vyzkoušet různé možnosti. Pokud se experimentátor z nějakého důvodu rozhodl pro jeden ze specifických správných časů a obdržel pole (m4 a (xk) ve stejnou dobu, pak by v další fázi měl použít některé matematické metody k aproximaci experimentálních bodů (m *, x ) nějaká přibližná světová čára procesu x = x (t) Extrapolací této čáry za počáteční interval pozorování může poskytnout prognózy o dalším průběhu procesu.

Je zajímavé zmínit výpočetní experiment určený k posouzení perspektiv použití navrženého algoritmu. Jako experimentální materiál byly zvoleny údaje o ročních odtocích řeky. Vakhsh (Tádžikistán) za 40 předchozích let. Za stejnou dobu byly pořízeny informace o dynamice Wolfova čísla – nejčastěji používaného integrálního indexu sluneční aktivity. Ten byl základem pro vývoj správného času procesu sluneční aktivity. Do nového času se změnily informace o nákladech řeky. Vakhsh a následně během pozorovacího období byla dána teoretická závislost rychlosti proudění vody jako funkce správné doby sluneční aktivity. Charakteristickým rysem výsledného harmonogramu je téměř periodické chování maximálních a minimálních nákladů. Náklady však nezůstávají konstantní.

(doba od práce nastává až do jejího dokončení v případě periodické činnosti nebo do doby, než systém zareaguje rukou prvního odchodu uživatele v případě interaktivní činnosti); nebo maximalizace spravedlnost(stejné množství času procesoru pro každý proces nebo obecněji odpovídající body v čase podle priority a pracovního zatížení každého procesu). V praxi jsou tyto cíle často v rozporu (např. propustnost versus latence), takže plánovač udělá vhodný kompromis. Preference se měří podle kteréhokoli z výše uvedených problémů v závislosti na potřebách a úkolech uživatele.

OS / 360 a nástupci

Aix

V systému AIX verze 4 existují tři možné významy zásady plánování vláken:

  • Nejprve vyšel ten první: Poté, co je vlákno s touto politikou naplánováno, je dokončeno, pokud není zablokováno, dobrovolně se vzdá kontroly nad procesorem, nebo se odeslání stane s vyšší prioritou vlákna. Zásadu plánování FIFO mohou mít pouze toky s pevnou prioritou.
  • Round Robin: Toto je podobné plánovači schémat AIX verze 3 v kruhovém provedení založeném na 10ms časových řezech. Když má vlákno PP kontrolu na konci časového úseku, přesune se na konec fronty vláken se stejnou prioritou. Zásadu plánování Round Robin mohou mít pouze vlákna s pevnou prioritou.
  • OSTATNÍ: Tato zásada je definována POSIX1003.4a v implementaci. V AIX verze 4 je tato zásada definována jako ekvivalent RR, kromě toho, že se vztahuje na vlákna s nepevnou prioritou. Přepočítání hodnoty priority běžícího vlákna na přerušení znamená, že vlákno může ztratit kontrolu, protože jeho hodnota priority vzrostla výše než u jiného vlákna. Toto je chování AIX verze 3.

Vlákna jsou primárně zajímavá pro aplikace, které se v současnosti skládají z více asynchronních procesů. Tyto aplikace mohou způsobit lehké zatížení systému, pokud jsou převedeny na vícevláknovou strukturu.

AIX 5 implementuje následující zásady plánování: FIFO, pivot a fair pivot. Politika FIFO se skládá ze tří různých implementací: FIFO, FIFO2 a FIFO3. Zásada kruhového obcházení se v systému AIX nazývá SCHED_RR a spravedlivé kruhové hodnocení se nazývá SCHED_OTHER.

Linux

Linux 2.4

Brain Fuck Scheduler (BFS), také vytvořený společností Colivas, je alternativou k CFS.

FreeBSD

FreeBSD používá vrstvenou frontu zpětné vazby s prioritami v rozmezí 0-255. 0-63 jsou vyhrazeny pro přerušení, 64-127 pro horní polovinu jádra, 128-159 pro uživatelská vlákna v reálném čase, 160-223 pro sdílení času pro uživatelská vlákna a 224-255 pro nečinná uživatelská vlákna. Stejně jako Linux také používá nastavení aktivní fronty, ale má také nečinnou frontu.

Přepínací verze předchozího algoritmu představuje algoritmus s nejmenší zbývající dobou. V souladu s tímto algoritmem plánovač pokaždé vybere proces s nejmenší zbývající dobou provádění. V tomto případě je také nutné předem znát dobu provádění úkolů. Když přijde nová úloha, její celková doba provedení se porovná se zbývající dobou provedení aktuální úlohy. Pokud je doba provádění nové úlohy kratší, aktuální proces se pozastaví a řízení se přenese na novou úlohu. Toto schéma umožňuje rychle obsluhovat krátké požadavky.

Třístupňové plánování

Dávkové systémy umožňují implementovat třívrstvé plánování, jak je znázorněno na obrázku. Jakmile do systému vstoupí nové úkoly, jsou nejprve umístěny do fronty uložené na disku. Vstup plánovač přístupu vybere úlohu a přenese ji do systému. Zbytek úkolů zůstává ve frontě.

Jakmile se úkol dostane do systému, vytvoří se pro něj odpovídající proces a může okamžitě vstoupit do boje o přístup k procesoru. Přesto je možná situace, kdy je procesů příliš mnoho a všechny se nevejdou do paměti, pak se některé z nich odstránkují na disk. Druhá úroveň plánování určuje, které procesy lze uložit do paměti a které na disk. Toto je hotovo plánovač paměti .

Plánovač paměti pravidelně sleduje procesy na disku, aby rozhodl, který z nich přesune do paměti. Mezi kritéria používaná plánovačem patří následující:

1. Jak dlouho uplynulo od vyprázdnění procesu na disk nebo načtení z disku?

2. Jak dlouho proces využívá procesor?

3. Jaká je velikost procesu (malé procesy se neruší)?

4. Jak důležitý je proces?

Třetí úroveň plánování je zodpovědná za přístup k procesoru pro procesy, které jsou ve stavu připravenosti. Když se mluví o „plánovači“, většinou to tak je plánovač procesoru ... Tento plánovač používá jakýkoli algoritmus vhodný pro danou situaci, s přerušením nebo bez přerušení. Některé z těchto algoritmů jsme již zvažovali a s dalšími se seznámíme.

Plánování v interaktivních systémech.

Cyklické plánování.

Jedním z nejstarších, nejjednodušších, spravedlivých a nejčastěji používaných algoritmů je plánovací algoritmus round-robin. Každý proces má určitý časový interval procesoru, tzv. časový úsek. Pokud proces na konci časového úseku stále běží, je přerušen a řízení je přeneseno na jiný proces. Samozřejmě, že pokud se proces zablokuje nebo předčasně skončí, dojde v tu chvíli k přechodu řízení. Implementace kruhového plánování je přímočará. Plánovač potřebuje pouze udržovat seznam procesů připravený. Když proces dosáhne svého časového limitu, je odeslán na konec seznamu.

Jediným zajímavým bodem tohoto algoritmu je kvantová délka. Přechod z jednoho procesu na druhý nějakou dobu trvá – je potřeba ukládat a načítat registry a paměťové karty, aktualizovat tabulky a seznamy, ukládat a znovu načítat paměť cache atd. efektivita, ale příliš velké kvantum může mít za následek pomalou odezvu na krátké interaktivní dotazy. Kvantová hodnota kolem 2 0 -5 0 ms je často rozumným kompromisem.

Prioritní plánování.

V cyklickém plánovacím algoritmu je důležitý předpoklad, že všechny procesy jsou si rovny. V situaci počítače s velkým počtem uživatelů tomu tak nemusí být. Například na univerzitě by měli být v první řadě obsluhováni děkani, pak profesoři, sekretářky, uklízečky a teprve potom studenti. Potřeba brát v úvahu takové vnější faktory vede k prioritnímu plánování. Základní myšlenka je jednoduchá: každému procesu je přiřazena priorita a řízení je přeneseno na proces připravený ke spuštění s nejvyšší prioritou.

Několik front.

Jeden z prvních prioritních plánovačů byl implementován v kompatibilním časově sdíleném systému (CTSS) Hlavním problémem systému CTSS bylo příliš pomalé přepínání procesů, protože v paměti počítače IBM 7094 byl pouze jeden proces. Každý přepínač znamenal uložení aktuálního procesu na disk

a čtení nového procesu z disku. Vývojáři CTSS si rychle uvědomili, že efektivita by byla lepší, kdyby procesům, omezeným kapacitou procesoru, byl přidělován větší úsek času, než kdyby dostávaly malé úseky, ale často. Na jednu stranu to sníží počet swapů z paměti na disk a na druhou to povede ke zhoršení doby odezvy, jak jsme již viděli.

V důsledku toho bylo vyvinuto řešení s prioritními třídami. Procesům třídy s nejvyšší prioritou bylo přiděleno jedno kvantum, procesům další třídy - dvě kvanta, další - čtyři kvanta atd. Když proces vyčerpal veškerý čas, který mu byl přidělen, přesunul se do nižší třída.

Jako příklad uvažujme proces, který potřebuje provádět výpočty přes 100 kvant. Nejprve mu bude přiděleno jedno kvantum, poté bude pumpováno na disk. Příště dostane 2 kvanta, pak 4, 8,16, 32, 64, i když použije pouze 37 z 64. V tomto případě bude potřebovat pouze 7 přenosů (včetně počátečního stažení) místo 100, což by pomocí cyklického algoritmu. Navíc, jak se ponoříte do fronty s prioritami, proces se bude spouštět stále méně často a procesor nechá na kratších procesech.

"Nejkratší proces je další"

Protože algoritmus Shortest Task First minimalizuje průměrnou dobu obratu v systémech dávkového zpracování, rádi bychom jej použili i v interaktivních systémech. Do jisté míry to možné je. Interaktivní procesy se nejčastěji řídí vzorem „čekání na příkaz, provedení příkazu, čekání na příkaz, provedení příkazu...“ Vzhledem k tomu, že provádění každého příkazu je považováno za samostatnou úlohu, můžete minimalizovat celkovou průměrnou dobu odezvy začněte nejdříve s nejkratším úkolem. Jediný problém je

při zjišťování, který z čekajících procesů je nejkratší.

Jedna z metod je založena na odhadu délky procesu na základě předchozího chování procesu. Tím se spustí proces s nejkratším odhadovaným časem. Předpokládejme, že předpokládaná doba provedení příkazu je T 0 a předpokládaná doba dalšího spuštění je T 1. Odhad času můžete zlepšit tím, že vezmete vážený součet těchto časů aT 0 + (1 - a) T 1. Volbou vhodné hodnoty pro a docílíme toho, že algoritmus odhadu rychle zapomene na předchozí spuštění nebo si je naopak dlouho zapamatuje. Vezmeme-li a = 1/2, dostaneme řadu odhadů:

To, 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 třech startech se váha T 0 v odhadu sníží na 1/8.

Metoda odhadu další hodnoty v řadě prostřednictvím váženého průměru předchozí hodnoty a předchozího odhadu se často označuje jako stárnutí. Tato metoda je použitelná v mnoha situacích, kdy je vyžadováno posouzení z předchozích hodnot. Nejjednodušší způsob, jak realizovat stárnutí, je při a = 1/2. Na každém kroku jen potřebujete

přidat novou hodnotu k aktuálnímu odhadu a snížit součet na polovinu (posunem o 1 bit doprava).

Zaručené plánování.

Zásadně odlišný přístup k plánování je dávat uživatelům skutečné sliby a následně je plnit. Zde je jeden slib, který lze snadno učinit a snadno splnit: pokud s vámi n uživatelů sdílí procesor, získáte 1/n výkonu procesoru.

A v systému s jedním uživatelem a n běžícími procesory dostane každý 1/n procesorových cyklů.

Aby systém splnil tento slib, musí sledovat alokaci CPU mezi procesy od okamžiku vytvoření každého procesu. Systém pak vypočítá množství procesorových zdrojů, na které má proces nárok, jako je čas od vytvoření dělený n. Nyní můžete vypočítat poměr času věnovaného procesu k času, na který má nárok. Výsledná hodnota 0,5 znamená, že procesu byla přidělena pouze polovina toho, co měla být alokována, a 2,0 znamená, že proces dostal dvakrát tolik, než by měl. Poté se proces spustí s nejmenším poměrem až

nebude větší než jeho nejbližší soused.

Plánování loterie.

Algoritmus je založen na distribuci losů do procesů pro přístup k různým zdrojům, včetně procesoru. Když se plánovač potřebuje rozhodnout, náhodně se vybere los a jeho držitel získá přístup ke zdroji. Pokud jde o přístup k CPU, „loterie“ může proběhnout 50krát za sekundu a vítěz získá 20 ms času CPU.

Důležitějším procesům lze dát další tikety, aby se zvýšila pravděpodobnost výhry. Pokud je v jednom procesu pouze 100 lístků a z toho 20, získá 20 % času procesoru. Na rozdíl od plánovače priorit, kde je velmi obtížné odhadnout, co znamená řekněme priorita 40, je v plánování loterie vše zřejmé. Každý proces obdrží procento zdrojů, které se zhruba rovná procentu lístků, které má.

Plánování loterie má několik zajímavých vlastností. Pokud například proces během vytváření získá několik tipů, pak jsou jeho šance na výhru v další loterii úměrné počtu tipů.

Interaktivní procesy si mohou podle potřeby vyměňovat vstupenky. Pokud tedy klientský proces odešle zprávu procesu serveru a poté jej zablokuje, může předat všechny své lístky procesu serveru, aby se zvýšila šance na spuštění serveru. Když proces serveru skončí, může vrátit všechny lístky zpět.

Spravedlivé plánování.

Dosud jsme předpokládali, že každý proces je řízen bez ohledu na to, kdo je šéf. Pokud tedy uživatel 1 vytvoří 9 procesů a uživatel 2 vytvoří 1 proces, pak pomocí cyklického plánování nebo v případě stejných priorit získá uživatel 1 90 % procesoru a uživatel 2 pouze 10.

Aby se takovým situacím předešlo, některé systémy věnují před plánováním pozornost vlastníkovi procesu. V tomto modelu dostane každý uživatel určitý podíl na procesoru a podle této skutečnosti si plánovač zvolí proces. Pokud v našem příkladu měl každý z uživatelů

Slíbí se 50 % procesoru, pak dostanou 50 % procesoru bez ohledu na počet procesů.

Plánování v systémech reálného času.

Čas hraje v systémech reálného času zásadní roli. Nejčastěji jedno nebo více externích fyzických zařízení generuje vstupní signály a počítač na ně musí v daném časovém období adekvátně reagovat.

Systémy reálného času se dělí na tvrdé systémy v reálném čase , což znamená, že pro každý úkol existují těsné termíny (musí být splněny) a flexibilní systémy v reálném čase ve kterých je porušení časového harmonogramu nežádoucí, ale přijatelné. V obou případech je program rozdělen do několika procesů, z nichž každý je předvídatelný. Tyto procesy jsou nejčastěji krátké a svou práci dokončí během vteřiny. Když se objeví externí signál, je na plánovači, aby zajistil dodržení plánu.

Externí události, na které musí systém reagovat, lze rozdělit na periodické(probíhající v pravidelných intervalech) a neperiodické(vzniká nepředvídatelně). Může existovat několik periodických proudů událostí, které musí systém zpracovat. V závislosti na době strávené zpracováním každé události nemusí být systém schopen zpracovat všechny události včas.


Podobné informace.


Často se vývojáři, zejména ti nezkušení, ztrácejí, když jsou požádáni o stanovení termínů pro úkoly. Schopnost plánovat je však velmi užitečná a potřebná dovednost, která pomáhá nejen v práci, ale i v životě. Rozhodli jsme se zeptat odborníků, jak se naučit správně plánovat a dodávat projekty včas.

Stručné závěry najdete na konci článku.

Vývojář obvykle potřebuje vzít v úvahu několik parametrů najednou, aby mohl odhadnout dobu provádění úlohy:

  1. Zkušenosti s prováděním takových úkolů a prací s tímto technologickým zásobníkem. Pokud musíte udělat něco zásadně nového, musíte být s hodnocením obzvláště opatrní.
  2. Zkušenosti s tímto klientem. Znáte-li zákazníka, můžete zhruba předvídat některé další požadavky a množství úprav.
  3. Kvalita kódu, se kterým se má pracovat. Toto je nejvlivnější faktor, kvůli kterému může být vše velmi zpožděno a obecně nejde podle plánu. Pokud má projekt testy, všude jsou pouze explicitní závislosti a funkčnost je dobře izolovaná, není vše tak děsivé. Mnohem horší je, pokud máte co do činění se starším kódem bez testů nebo s kódem přesyceným implicitními závislostmi. Věci jako „kouzelné funkce“ (kdy je těžké vidět konečný zásobník volání z kódu) a duplikace kódu (když potřebujete upravit několik nezávislých sekcí, abyste změnili jakoukoli funkci), mohou také věci komplikovat.

Chcete-li se naučit, jak adekvátně posoudit načasování práce, musíte neustále cvičit. Na začátku své práce jsem dělal přesně toto: odhadl jsem čas na dokončení jakéhokoli příchozího úkolu, i když to nikdo nevyžadoval, a pak jsem sledoval, jak přesně se mi podařilo dostat se do svého odhadu. V procesu dokončování úkolu jsem zaznamenal, které akce zaberou více času. Pokud něco výrazně zvýšilo termín, pamatoval si tento okamžik a vzal to v úvahu v dalších hodnoceních.

K objektivnímu posouzení času potřebného čistě pro práci by se měla přidat malá rezerva na pokrytí situací vyšší moci. Často se odhaduje jako procento dokončení hlavního úkolu, ale pro každého je to jiné: někdo přidá 20 % času, někdo 10 % a někdo 50 %.

Je také užitečné analyzovat důvody zmeškání lhůt po každém větším porušení lhůty. Pokud nemáte dostatečnou kvalifikaci, musíte zapracovat na svých slabých stránkách. Pokud byl problém organizační - pochopit, co bránilo normální práci.

Propagujte Dolní

, Technický ředitel Centra pro inovativní technologie a řešení „Jet Infosystems“

Velké množství článků je věnováno metodám hodnocení složitosti projektu včetně doby trvání práce a jednotlivých úkolů. To je však dosud příčinou konfliktů jak uvnitř projektového týmu, tak při komunikaci se zákazníkem.

Hlavním pomocníkem při posuzování je zkušenost. Pokuste se nějak korelovat nový úkol s již splněnými. Pokud vytváříte zprávu, podívejte se, jak dlouho podobná zpráva v minulosti trvala. Pokud děláte něco nového, zkuste se rozdělit na známé kousky a ocenit je. Pokud je úkol zcela nový, věnujte nějaký čas studiu (ještě lépe - koordinujte tento čas s osobou, která úkol zadává).

Věnujte pozornost doprovodným fázím - pokud potřebujete vyvinout službu, pak by do hodnocení mělo být zahrnuto i testování jednotek (a možná nejen jednotky), příprava testovacích dat zabere určitou dobu. Zvažte integraci s jinými službami atd. Věnujte čas opravě chyb, které sami nebo s pomocí testerů najdete. Spoustu času lze ztratit „neviditelnými“ úkoly. Existuje například hodnocení pro vývoj a existuje hodnocení pro testování, ale přenos artefaktu pro testování může být spojen s rozmístěním stojanů. Proto je důležité si celý proces v duchu představit, aby nic neuniklo.

Po stanovení pracnosti je nutné do kalendáře zařadit nová zaměstnání, nezapomínat na další souběžně probíhající úkoly a činnosti.

A nezapomeňte, že plány jsou k ničemu, ale plánování je neocenitelné. Naučte se upravovat plány včas, udržujte všechny zájemce a eskalujte včas, aby zmeškané termíny nikoho nepřekvapily.

Propagujte Dolní

Otázka, na kterou nelze odpovědět stručně. Pokud by to bylo snadné, nebyl by problém s nedodržením termínů.

Aby byly termíny vývoje předvídatelnější, musíte nejprve pochopit důvody, proč programátoři neustále dělají chyby.

Prvním důvodem je, že většina úkolů, které programátor dělá, je do té či oné míry jedinečná. To znamená, že programátor s největší pravděpodobností udělá takový úkol poprvé. Nemá dobrou představu o tom, jak dlouho bude práce trvat. Pokud se jedná o programátora se solidními zkušenostmi a musel provést podobný úkol, bude jeho hodnocení blíže realitě.

Jednoduše řečeno, pokud jste nikdy nekopali příkopy, nemůžete přesně říci, jak dlouho vám bude trvat vykopat příkop široký 30 cm, hluboký 60 cm a dlouhý 20 metrů. Pokud jste již dříve kopali, váš odhad pracovní doby se bude mnohem více přibližovat skutečné době trvání práce.

Druhým důvodem je, že programátoři jsou ze své podstaty optimističtí. To znamená, že s ohledem na úkol, výběr možnosti implementace pro něj, vyhodnocení vylepšení vývojář očekává, že vše bude fungovat, jak očekává. A nemyslí na problémy, které ho cestou potkají. Často je nedokáže předvídat. Existuje například úkol, který může programátor splnit pomocí knihovny open source softwaru třetí strany. Ve fázi posuzování si ho našel na internetu, přečetl si jeho popis – vyhovuje mu. A dokonce správně odhadl objem svého díla, který má zabudovat do využití této knihovny. Vůbec ale nepředvídal, že v prostředí jeho softwarového produktu v této knihovně dojde k chybě.

Vývojář bude muset nejen zabudovat použití knihovny do svého kódu, ale také opravit chybu v knihovně samotné. A často vývojář neposkytuje čas na opravu svých chyb. Jak ukazují statistiky, testování a oprava chyb může zabrat asi 50 % času stráveného kódováním. Toto číslo závisí na kvalifikaci vývojáře, prostředí, použitých vývojových postupech (například testy jednotek tuto dobu výrazně zkracují a celková doba trvání / pracnost vývojového úkolu se ukazuje jako nižší).

Pokud se vrátíme k přirovnání s bagrem, tak bagr nepočítal s tím, že se mu zlomí lopata a bude muset dvě hodiny hledat nový řez.

Třetím důvodem jsou nepředvídatelné požadavky. Žádná z oblastí výroby materiálů, se kterou zákazníci rádi srovnávají vývoj softwaru, nemá takový proud nových požadavků. Představte si průjezd bagru, který kopal 19 metrů z 20 a vyslechl od zákazníka přání, aby příkop nešel přímočaře, ale jako had o délce ramen 97 centimetrů.

Jak se s tím vším vypořádat a jak žít v podmínkách takové nejistoty? Snížení nejistoty a budování časových rezerv.

Nejjednodušší způsob, jak přiblížit svá očekávání realitě, je použít vtipné pravidlo „Pí“. Po obdržení odhadu od vývojáře (z hlediska času nebo pracovní náročnosti) jej musíte vynásobit číslem Pi (= 3,14159). Čím zkušenější developer odhad provedl, tím může být tento koeficient nižší.

Je bezpodmínečně nutné procvičit si rozklad původního problému na malé problémy o velikosti maximálně 4 hodin. Čím podrobnější je rozklad, tím vyšší je pravděpodobnost, že se odhad bude blížit skutečnému vstupu práce/době trvání.
Pokud se vrátíme k alokaci rezervy - tato doba by měla být přidělena na konci projektu. Je špatným zvykem dělat si rezervu a zahrnout ji pro každý úkol. Parkinsonův zákon „Práce vyplňuje všechen čas, který je jí přidělen“ je přísně dodržován.

Pokud shrnete krátký „celkem“, budou pro správné určení načasování práce užitečné následující akce:

  • provést rozklad práce, rozdělit úkol na co nejpodrobnější kroky;
  • prototypování;
  • omezit provádění dříve nepředvídaných požadavků. Neznamená to, že je není nutné provést, ale je vhodné tyto požadavky zvýraznit a dohodnout se se zákazníkem na změně načasování a nákladů na jejich realizaci;
  • vzít v úvahu čas na stabilizaci roztoku;
  • používat postupy ke zlepšení kvality kódu, například psát unit testy;
  • stanovit všeobecnou rezervu.

No a pamatujte, že pokud nějaká skutečnost překročí váš odhad o 30 %, pak je to velmi dobrý výsledek.

Propagujte Dolní

Pro co nejpřesnější posouzení potřebujete zkušenosti s reálným vývojem a v konkrétní oblasti. Existují ale obecná pravidla, která pomohou vyhnout se chybám v plánování a problémům při předání díla zákazníkovi. Tato pravidla bych popsal následovně.

Nejprve musíte úkolu porozumět. To se zdá být zřejmé a přímo nesouvisí s posouzením načasování, ale ve skutečnosti je to klíčový bod. I u vážných velkých projektů je jedním z hlavních faktorů selhání a zpoždění problém s definováním požadavků. Pro začínající vývojáře je to bohužel vážný problém – nečtou TOR nebo ho čtou a rozumí mu velmi selektivně (z deseti bodů si zapamatovali a dokončili pět a zbytek si zapamatovali při odevzdání výsledku). Je jasné, že špatně pochopený úkol nelze řádně a včas zrealizovat.

Dále - odhadněte čas na samotný vývoj. Zvláštností programování je, že neexistují absolutně identické úlohy. Tím je naše práce zajímavější, ale načasování je složitější. Dobře zde funguje rozklad, tzn. rozdělení komplexního jedinečného úkolu do sekvence malých, známých dílčích úkolů. A každý z nich se již dá adekvátně odhadnout na hodiny. Sečteme odhady dílčích úkolů – a dostaneme odhad celého problému.

Tento odhad obvykle zahrnuje pouze přímé náklady na kódování. To je bezpochyby nejdůležitější část vývoje, ale zdaleka ne jediná (a často - ne nejobjemnější). Kompletní realizace úkolu dále zahrnuje přečtení a ujasnění technické specifikace, jednání s kolegy nebo zákazníkem, odladění a testování, vypracování dokumentace, předání výsledku (předvedení zákazníkovi a případné úpravy na základě jeho připomínek). Jak dlouho vám tyto akce zaberou, ukáže pouze zkušenost. Zpočátku je důležité je alespoň nezapomenout zohlednit ve výpočtech a přibližný odhad času si lze vyžádat od zkušenějších kolegů.

Takže vezmeme odhad nákladů na kódovací práci, přidáme odhad nákladů na další práci - a dostaneme požadovaný odhad času na dokončení úkolu. Ale to není vše! Je nutné uvést plánované datum dokončení úkolu. Bylo by chybou jednoduše vzít a vydělit mzdové náklady (v hodinách) 8 hodinami a přidat je k aktuálnímu datu. V reálném životě vývojář nikdy (no, skoro nikdy) nepracuje 100 % času na jednom konkrétním úkolu. Určitě budete muset věnovat čas jiné práci – důležité, ale nesouvisející přímo s tou hlavní. Například pomoc kolegům, školení, reportování atd. Obvykle se při plánování věří, že 60–70 % pracovní doby je věnováno přímo práci na aktuálním projektu. Kromě toho musíte počítat s možnými zpožděními, které vám zabrání v nepřetržité práci na úkolu. Například, pokud k tomu potřebujete komunikovat s jinými lidmi (kolegy, zákazníky), vezměte v úvahu jejich zaměstnání, pracovní rozvrh atd.

Zde jsou základní pravidla, která podle mého názoru pomohou developerovi vyhnout se problémům s odhadováním a dodržováním termínů. Klíčové je navíc shromažďování vlastních zkušeností jak při realizaci úkolů, tak při hodnocení. Například je velmi užitečné po dokončení úkolu porovnat svůj původní odhad se skutečným časovým rámcem a vyvodit závěry pro budoucnost. A samozřejmě stojí za to nastudovat si zkušenosti někoho jiného. Na téma bych doporučil knihu S. McConnella „How Much Does a Software Project Cost“ a S. Arkhipenkova „Lectures on Software Project Management“.

Propagujte Dolní

Při posuzování a plánování termínů je nutné:

  1. Rozložte úkol na malé funkční části, aby bylo jasné, jak dlouho bude trvat vývoj každého takového kousku.
  2. Paralelně s rozkladem se jistě objeví další otázky týkající se funkčnosti, které nebyly popsány v prohlášení o problému. Na takové otázky je nutné získat odpovědi, protože to přímo souvisí s rozsahem práce a následně s načasováním.
  3. Přidejte do konečného hodnocení nějaké procento rizik. To je stanoveno empiricky. Začít můžete například s riziky 10-15 %.
  4. Uvědomte si, kolik hodin denně je programátor ochoten věnovat úkolu.
  5. Výsledný odhad vydělíme počtem hodin, které denně alokujeme, a získáme počet dní potřebných k realizaci.
  6. Zaměřujeme se na kalendář a požadovaný počet dní k vyplnění. Zohledňujeme víkendy a další dny, kdy se programátor nebude moci s úkolem vypořádat, a také datum zahájení práce (ne vždy je vývojář připraven vzít úkol do práce ve stejný den). Získáme tak datum zahájení a ukončení práce.

Propagujte Dolní

V naší společnosti prochází plánování úkolů vždy několika fázemi. Po obchodní stránce formulujeme 5-6 strategických cílů na rok. Jedná se o úkoly na vysoké úrovni, například zvýšit parametr o určité procento. Různé divize společnosti dále tvoří obchodní úkoly pro všechny IT týmy. Termíny pro tyto úkoly obdrží prvotní hrubý odhad, který často tvoří všichni členové týmu – manažer, analytik, vývojář a tester. Po obdržení tohoto hodnocení podnik upřednostňuje úkoly s ohledem na strategické cíle společnosti. K tomu napomáhají průřezové strategické cíle, u kterých je zřejmé, že všichni pracujeme pro nějakou společnou věc, neexistuje situace, kdy někdo táhne jen jejich směrem. Sbíráme sprinty z přesně odhadnutých úkolů. Některé týmy je mají čtvrtletně, některé měsíčně. Týmy přesně vyhodnotí několik problémů, které podle předběžných odhadů spadají do dalšího sprintu. Velké úkoly jsou rozčleněny na nižší úrovně, za každý je zodpovědný konkrétní interpret a je to on, kdo dává přesné hodnocení.

V této fázi je důležité nezapomenout přidat čas navíc na opravu chyb, protože se nemýlí jen ten, kdo nic nedělá. To dobře chápou jak majitel produktu, tak obchodní zákazníci. Požadovaná časová rezerva přitom musí být adekvátní: developerovi, který si na jednoduchý úkol nastaví příliš dlouhý termín, nikdo neporozumí, bude požádán, aby rozhodnutí zdůvodnil. Nejtěžší na tom je vysvětlit firmě, proč refaktorování nějakou dobu trvá. Jsme naší společnosti vděčni za to, že se nám to čas od času daří, protože refaktoring vede v konečném důsledku k odlehčení infrastruktury a uvedení věcí do pořádku v kódu, což zvyšuje stabilitu systému a může výrazně urychlit vývoj nových funkcí.

Někdy dochází k chybám v hodnocení. Dle mého názoru je nemožné, aby se tomu vývojové oddělení ve velkých společnostech s rozvinutou infrastrukturou zcela vyhnulo. V tomto případě je důležité, aby developer včas informoval svého manažera o tom, co se děje, a ten zase měl čas varovat byznys a něco „přehrát“ v obecných plánech firmy. V takovém režimu je mnohem správnější pracovat, než se zběsile snažit udělat to, co trvá 5 dní ve 3 dnech, a pak se utápět ve velkém množství chyb, které kvůli takovému spěchu vznikly.

Propagujte Dolní

Správná odpověď na obě části otázky [jak se naučit správně naplánovat a dodat projekt včas - Ed.] - Zkušenosti. Neexistují žádné jiné způsoby, jak „poznat zen“. Podle teorie rozhodování lze jakékoli přesné závěry budovat pouze na základě analýzy řady již dostupných dat. A čím více těchto údajů, tím přesnější je konečná předpověď a hodnocení.

Slovy Herberta Shawa: "Zkušenost je škola, ve které se člověk dozví, jaký byl předtím hlupák." Z toho plyne celkem jednoduchý závěr: pokud již programátor má zkušenosti, které korelují s daným úkolem, může se na ně spolehnout, pokud ne, na zkušenosti svých „kolegů v obchodě“.

Dále musíte pochopit, že přímé plánování je úkol, který lidé dělají velmi, velmi špatně, zejména ve vývoji. Při odhadování termínů splatnosti je dobrou praxí zavést do původního odhadu „opravné faktory“. Tato metrika může kolísat v rozmezí od 1,5 do 3 v závislosti na zkušenostech vývojáře a souhrnu stupňů nejistoty řešených úkolů v rámci projektu.

Propagujte Dolní

Při určování načasování je důležité vzít v úvahu mnoho faktorů.

Například pracovní zkušenosti. Jak jasně si představujete rozsah připravovaného díla? Už jste něco takového dělali? Je jasné, že čím více zkušeností, tím rychleji bude práce hotová.

Významnou roli při stanovení termínů hraje dobře napsané technické zadání. S tím v naší oblasti je to velmi obtížné. Klient sám často neví, co chce, proto vám doporučuji strávit den nebo dva navíc, ale získat od klienta jasnou představu o požadovaném výsledku. Je důležité, aby tato prezentace byla oboustranná. A až poté můžete začít vyjednávat o částce a podmínkách.

Vždy také zahrňte rizika. Pro začátečníky doporučuji vynásobit předpokládanou dobu vedení dvěma. Koneckonců, je lepší dodat projekt s předstihem a růst jako specialista v očích zákazníka, než jej odevzdat později a zničit si pověst.

Propagujte Dolní

Obecné doporučení - vývojář se potřebuje naučit správně rozkládat úkoly, vždy hledat možná úskalí, spoléhat se na vlastní zkušenosti a nezapomenout včas upozornit zákazníky a kolegy, pokud se úkol nepodaří vyřešit ve stanoveném časovém horizontu.

Sestavení jasného plánu je mnohem obtížnější než stanovení termínu pro konkrétní úkol. Zároveň je důležité nejen dodat projekt včas, ale také se ujistit, že vámi vyvinutý systém správně řeší obchodní problémy. Zde týmům IT pomáhají různé metodiky vývoje softwaru: od RUP a MSF po SCRUM a další agilní formáty. Výběr nástrojů je velmi široký a mnoho našich zákazníků chce předem pochopit, jak s nimi budeme v projektu pracovat, jaké zásady dodržujeme.

Mimochodem, téma Agile se nyní přibližuje byznysu, a to i v jednotlivých projektech veřejnému sektoru, protože principy této metodiky umožňují realizovat projekty velmi rychle a řídit očekávání zákazníka v každé iteraci. Například v Agilním týmu prakticky neprobíhají sáhodlouhé diskuse se zákazníkem. Zapomeňte na desítky stránek popisujících zbytečné technické detaily, jako je rychlost zobrazování rozbalovacích nabídek. Dejte zákazníkovi možnost vyzkoušet si střední verzi systému, pak pro vás bude mnohem snazší si vzájemně porozumět.

Agilní tým vše společně naplánuje a určí optimální úroveň mzdových nákladů, které budou potřeba k vyřešení konkrétního problému. Například jedna z technik se nazývá „Plánování pokeru“, kdy každý účastník anonymně uvede svůj odhad požadované zátěže pro konkrétní úkol. Poté tým určí průměrnou váhu úkolu v příběhových bodech nebo člověkohodinách a rozděluje úkoly podle principu „kdo má co rád“. Zároveň se tým každý den schází na 15minutové schůzce, kdy každý během pár minut mluví o stavu svých aktuálních úkolů, včetně hlášení vzniklých potíží. Tým rychle odstraní zjištěný problém, proto se zákazník co nejrychleji podívá na další fázi práce programátora. Vývojáři nezdržují termíny pro dokončení úkolů kvůli neochotě znovu vytáhnout tým nebo marným pokusům přijít na to sami, což zabíjí drahocenný čas. Mimochodem, s takovými mini-stavy mají vývojáři touhu ukázat svou nejlepší stránku, ukázat, že jste zodpovědní za svou práci. Opravdu motivuje a sebedisciplínuje.