Найчастіше розробники, особливо недосвідчені, губляться, коли їх просять позначити термін виконання завдань. Проте вміння планувати - дуже корисна і потрібна навичка, яка допомагає не тільки в роботі, а й у житті. Ми вирішили дізнатися у експертів, як навчитися правильно планувати та здавати проекти вчасно.
Короткі висновки можна побачити наприкінці статті.
Розробнику зазвичай потрібно врахувати відразу кілька параметрів, щоб оцінити час виконання завдання:
- Досвід виконання таких завдань та роботи з даним технологічним стеком. Якщо належить робити щось нове, потрібно бути особливо обережним з оцінкою.
- Досвід роботи з цим клієнтом. Знаючи замовника, можна приблизно передбачити деякі додаткові вимоги та обсяг правок.
- Якість коду, з яким належить працювати. Це найвпливовіший фактор, через який все може сильно затягнутися і взагалі піти не за планом. Якщо у проекті є тести, скрізь лише явні залежності та функціональність добре ізольована, все не так страшно. Набагато гірше, якщо ви маєте справу з легасом без тестів або з кодом, перенасиченим неявними залежностями. Ускладнювати справу можуть також такі речі, як магічні функції (коли по коду важко побачити кінцевий стек викликів) і дублювання коду (коли для зміни будь-якої функціональності потрібно правити кілька незалежних ділянок).
Щоб навчитися адекватно оцінювати термін роботи, потрібно постійно практикуватися. На початку своєї роботи я чинив саме так: оцінював час на виконання будь-якого вхідного завдання, навіть якщо цього ніхто не вимагав, а потім дивився, наскільки точно вдалося потрапити у свою оцінку. У процесі виконання завдання наголошував на тому, які дії займають більше часу. Якщо щось сильно збільшувало термін, запам'ятовував цей момент та враховував його у наступних оцінках.
До об'єктивної оцінки часу, потрібного чисто працювати, слід додавати невеликий запас покриття форс-мажорних ситуацій. Його часто оцінюють у відсотках від виконання основного завдання, але у всіх він різний: хтось додає 20% часу, хтось – 10%, а хтось – 50%.
Корисно також аналізувати причини зривів термінів після кожного серйозного порушення дедлайну. Якщо забракло кваліфікації, треба попрацювати над своїми слабкими місцями. Якщо проблема була організаційною – зрозуміти, що завадило нормально працювати.
Підвищити Зменшити
, технічний директор центру інноваційних технологій та рішень «Інфосистеми Джет»
Методикам оцінки трудомісткості проекту, включаючи тривалість робіт та окремих завдань, присвячено велику кількість статей. Однак досі це є причиною конфліктів як усередині проектної команди, так і при спілкуванні із замовником.
Основний помічник в оцінці – досвід. Спробуйте якось зіставити нове завдання із вже зробленими. Якщо ви робите звіт, подивіться, скільки часу зайняв схожий звіт у минулому. Якщо ви робите щось нове, спробуйте розбити на певні частини та оцінити їх. Якщо завдання зовсім нове, виділіть час вивчення (ще краще - погодьте цей час із тим, хто ставить завдання).
Зверніть увагу на супутні етапи - якщо потрібно розробити сервіс, то в оцінку необхідно включити також і юніт-тестування (а може і не тільки юніт), певний час займе підготовка тестових даних. Слід продумати інтеграцію з іншими сервісами тощо. Закладіть час на виправлення дефектів, які ви знайдете самостійно або за допомогою тестувальників. Багато часу може витікати у «непомітні» завдання. Наприклад, є оцінка з розробки і є оцінка тестування, але передача артефакту на тестування може бути пов'язана з розгортанням стендів. Тому важливо уявити собі весь процес, щоб нічого не проґавити.
Після визначення трудомісткості необхідно включити нові роботи в календар, не забувши про інші завдання та активності, що йдуть паралельно.
І не забувайте, що плани марні, але планування безцінне. Вчіться вчасно коригувати плани, тримати в курсі всіх зацікавлених та своєчасно ескалювати, щоб провалені терміни не виявилися ні для кого несподіванкою.
Підвищити Зменшити
Питання, на яке неможливо відповісти у короткій формі. Якби це було просто, то проблеми порушення термінів не було б.
Щоб зробити терміни закінчення розробки більш передбачуваними, треба спочатку зрозуміти причини, через які програмісти постійно помиляються.
Перша причина – більшість завдань, які робить програміст, є тією чи іншою мірою унікальними. Тобто, швидше за все, програміст робитиме подібне завдання вперше. Він недостатньо добре уявляє, скільки займе ця робота. Якщо це програміст із солідним досвідом і йому доводилося виконувати подібне завдання, його оцінка буде ближчою до реальності.
Вдамося до простої аналогії - якщо ви ніколи не копали канави, ви не можете точно сказати, скільки часу у вас займе викопати траншею 30 см завширшки, 60 см завглибшки і 20 метрів завдовжки. Якщо ви раніше копали, оцінка часу роботи у вас буде набагато ближчою до фактичної тривалості роботи.
Друга причина – програмісти за своєю природою оптимісти. Тобто, розглядаючи завдання, підбираючи для неї варіант реалізації, даючи оцінку доопрацюванням, розробник очікує, що все буде працювати так, як він передбачає. І не думає про ті проблеми, які йому зустрінуться на шляху. Найчастіше він не може їх передбачати. Наприклад, є завдання, що програміст може реалізувати, використовуючи сторонню open-source програмну бібліотеку. На етапі оцінки він знайшов її в інтернеті, прочитав її опис – вона йому підходить. І навіть вірно оцінив обсяг своєї роботи, щоб вбудувати використання цієї бібліотеки. Але він зовсім не передбачив, що серед його програмного продукту в цій бібліотеці виникне помилка.
Розробнику доведеться не тільки вбудувати використання бібліотеки у свій код, але й виправити помилку в бібліотеці. А ще часто розробник не передбачає часу на виправлення своїх помилок. Як показує статистика, тестування та виправлення помилок може займати близько 50% від часу, що було витрачено на кодинг. Цифра залежить від кваліфікації розробника, оточення, використовуваних практик розробки (наприклад, юніт тести істотно скорочують цей час і підсумкова тривалість/трудомісткість завдання з розробки виходить менше).
Якщо повернутись до аналогії із землекопом, то землекоп не припускав, що в нього зламається лопата і доведеться витратити дві години на пошуки нового живця.
Третя причина – непередбачені вимоги. У жодній галузі матеріального виробництва, з якими так люблять порівнювати замовники розробку ПЗ, немає такого потоку нових вимог. Уявіть собі пасаж землекопа, який викопав 19 метрів із 20 і почув від замовника побажання, щоб канава йшла не прямою, а змійкою з довжиною плеча 97 сантиметрів.
Як з усім цим боротися і як жити за умов подібної невизначеності? Зменшуючи невизначеність та закладаючи резерв часу.
Найпростіший спосіб привести свої очікування ближче до реальності – це використати жартівливе емпіричне правило «Пі». Отримавши оцінку від розробника (за термінами чи трудомісткості), треба помножити на число Пі (= 3,14159). Чим досвідченіший розробник робив оцінку, тим менше може бути цей коефіцієнт.
Обов'язковою є практика декомпозиції вихідної задачі до дрібних завдань розміром трохи більше 4 годин. Чим детальніше виконано декомпозицію, тим вище шанси, що оцінка виявиться близька до фактичної трудомісткості/тривалості.
Якщо повернутися до виділення резерву – цей час має бути виділено наприкінці проекту. Погана практика робити резерв і включати його для кожного завдання. Закон Паркінсона "Робота заповнює весь час, відпущений на неї" виконується неухильно.
Якщо підвести коротке «Разом», то щоб правильно визначити терміни виконання роботи, корисні будуть наступні дії:
- виконати декомпозицію робіт, розбити завдання на якомога детальніші кроки;
- провести прототипування;
- обмежити реалізацію непередбачених раніше вимог. Це не означає, що їх не треба робити, але доцільно виділяти ці вимоги та погоджувати із замовником зміну термінів та вартості для їх реалізації;
- врахувати час на стабілізацію рішення;
- використовувати практики підвищення якості коду, наприклад, писати юніт тести;
- закласти загальний резерв.
Ну, і пам'ятати, що якщо факт перевищує вашу оцінку на 30% - це дуже хороший результат.
Підвищити Зменшити
Для максимально точної оцінки потрібен досвід реальної розробки, причому у конкретної області. Але є й загальні правила, які допоможуть уникнути помилок у плануванні та проблем при здачі роботи замовнику. Я би описав ці правила так.
По-перше, треба зрозуміти завдання. Це начебто очевидно і не стосується безпосередньо оцінки термінів, але насправді це ключовий момент. Навіть у серйозних великих проектах одним із основних факторів невдачі та затягування термінів є проблема у визначенні вимог. У розробників-початківців, на жаль, це серйозна проблема - не читають ТЗ або читають і розуміють дуже вибірково (з десяти пунктів запам'ятали і виконали п'ять, а про тих, що залишилися, згадали вже при здачі результату). Зрозуміло, що неправильно зрозуміле завдання неможливо правильно реалізувати вчасно.
Далі - оцінити час на розробку. Особливість програмування у цьому, що немає абсолютно однакових завдань. Це робить нашу роботу цікавішою, але оцінку термінів – складніше. Тут добре працює декомпозиція, тобто. поділ складної унікальної задачі на послідовність маленьких знайомих підзадач. А кожну з них уже можна оцінити у годиннику достатньо адекватно. Складемо оцінки підзавдань – і отримаємо оцінку всього завдання.
Як правило, така оцінка включає лише витрати безпосередньо на кодування. Це, безумовно, найважливіша частина розробки, але не єдина (а часто - і найбільша об'ємна). Повне виконання завдання включає ще читання і прояснення ТЗ, зустрічі з колегами або замовником, налагодження і тестування, складання документації, здачу результату (демонстрацію замовнику і можливі переробки за його зауваженнями). Скільки часу у вас піде на ці дії, підкаже тільки досвід. Спочатку важливо, як мінімум, не забути їх врахувати в розрахунках, а приблизну оцінку часу можна запитати у більш досвідчених колег.
Отже, ми беремо оцінку трудовитрат на кодування, додаємо оцінку витрат на додаткові роботи - і отримуємо оцінку часу на виконання завдання. Але це ще не все! Потрібно позначити заплановану дату завершення завдання. Помилка буде просто взяти і розділити трудовитрати (у годинах) на 8 годин і додати до поточної дати. У реальній практиці розробник ніколи (ну гаразд, майже ніколи) не працює 100% часу над одним конкретним завданням. У вас обов'язково буде витрачати час на інші роботи - важливі, але не пов'язані безпосередньо з головною. Наприклад, допомога колегам, навчання, складання звітів тощо. Зазвичай, при плануванні вважають, що безпосередньо на роботу над поточним проектом йде 60-70% робочого часу. Додатково треба врахувати ще можливі затримки, які дадуть вам безперервно працювати над завданням. Наприклад, якщо для цього вам потрібно взаємодіяти з іншими людьми (колегами, замовниками), то враховуйте їхню зайнятість, графік роботи тощо.
Ось основні правила, які, як на мене, допоможуть розробнику уникнути проблем в оцінці та дотриманні термінів. Крім цього, ключовим є накопичення власного досвіду як у реалізації завдань, так і в оцінці. Наприклад, дуже корисно після завершення завдання порівнювати свою початкову оцінку з фактичними термінами та робити висновки на майбутнє. І, звісно, варто вивчити чужий досвід. Я б порекомендував на тему книги С. Макконнелла «Скільки коштує програмний проект» та С. Архипенкова «Лекції з управління програмними проектами».
Підвищити Зменшити
При оцінці та плануванні термінів необхідно:
- Декомпозувати завдання до невеликих функціональних шматків таким чином, щоб було чітке розуміння скільки часу займе розробка кожного такого шматка.
- Паралельно з декомпозицією обов'язково виникатимуть додаткові питання щодо функціональності, яка не була описана у постановці завдання. Необхідно отримати відповіді такі питання, оскільки це безпосередньо стосується обсягу робіт і, отже, термінів.
- До підсумкової оцінки додати певний відсоток ризиків. Це визначається досвідченим шляхом. Можна почати, наприклад, із ризиків розміром 10–15 %.
- Зрозуміти, скільки годин на день програміст готовий виділяти виконання завдання.
- Ділимо підсумкову оцінку на кількість годин, які виділяємо на день, та отримуємо кількість днів, необхідних на реалізацію.
- Орієнтуємось на календар та необхідну кількість днів на виконання. Враховуємо вихідні та інші дні, коли програміст не зможе займатися завданням, а також дату початку робіт (не завжди розробник готовий взяти завдання на роботу в той же день). Таким чином, отримуємо дату початку та закінчення робіт.
Підвищити Зменшити
У нашій компанії планування завдань проходить кілька етапів. На стороні бізнесу ми формулюємо 5-6 стратегічних цілей на рік. Це високорівневі завдання, наприклад підвищити будь-який параметр на стільки відсотків. Далі різні підрозділи компанії формують бізнес-завдання на всі команди ІТ. Терміни з цих завдань отримують первинну грубу оцінку, яка часто формується всіма учасниками команди – менеджером, аналітиком, розробником та тестувальником. Отримавши цю оцінку, бізнес пріоритезує завдання з огляду на стратегічні цілі компанії. У цьому допомагають наскрізні стратегічні цілі, з ними стає очевидним, що ми працюємо на якусь спільну справу, немає такої ситуації, коли хтось тягне тільки у свій бік. З точно оцінених термінів завдань ми збираємо спринти. У деяких команд вони квартальні, у деяких – місячні. Кільком завданням, що за попередньою оцінкою потрапляють до наступного спринту, команди дають точну оцінку. Великі завдання розбиваються більш низькорівневі, кожну у тому числі відповідає конкретний виконавець, саме і дає точну оцінку.
На даному етапі важливо не забувати додавати запасу часу на виправлення багів, адже не помиляється тільки той, хто нічого не робить. Це чудово розуміють і Product Owner, і бізнес-замовники. При цьому необхідний запас часу має бути адекватним: ніхто не зрозуміє розробника, який поставить простому завданню надто довгий термін виконання, його попросять обґрунтувати рішення. Найскладніше - пояснити бізнесу, навіщо потрібен час на рефакторинг. Ми вдячні нашій компанії за те, що періодично нам це вдається, адже в кінцевому рахунку рефакторинг веде до полегшення інфраструктури та наведення порядку в коді, що підвищує стабільність системи та може суттєво прискорити розробку нових функцій.
Іноді помилки в оцінці все ж таки виникають. Відділу розробки у великих компаніях із розвиненою інфраструктурою повністю уникнути цього, на мою думку, неможливо. В даному випадку важливо, щоб розробник вчасно інформував про те, що відбувається свого менеджера, а той, у свою чергу, встиг попередити бізнес і щось переграти в загальних планах компанії. У такому режимі працювати набагато правильніше, ніж судомно намагатися зробити за 3 дні те, що займає 5, а потім потонути у великій кількості помилок, що виникли через такий поспіх.
Підвищити Зменшити
Правильна відповідь на обидві частини питання [як навчитися правильно планувати та здавати проект вчасно - Ред.] - досвід. Інших шляхів «пізнання Дзена» немає. Відповідно до теорії прийняття рішень, скільки-небудь точні висновки можна будувати тільки на основі аналізу низки вже наявних даних. І чим більше цих даних – тим точніше підсумковий прогноз та оцінка.
Говорячи словами Герберта Шоу: «Досвід - це школа, в якій людина дізнається, яким дурнем вона була раніше». Звідси випливає досить простий висновок: якщо в програміста вже є досвід, що корелює з поставленим завданням - він може спертися на нього, якщо ні - на досвід «колег по цеху».
Далі потрібно розуміти, що пряме планування термінів – завдання, з яким люди справляються дуже і дуже погано, особливо у розробці. Оцінюючи термінів здачі хорошої практикою вважається запровадження «поправочних коефіцієнтів» на вихідну оцінку. Дана метрика може коливатися в інтервалі від 1,5 до 3, залежно від досвіду розробника та сукупності ступенів невизначеності завдань, які вирішуються в рамках проекту.
Підвищити Зменшити
При визначенні термінів важливо враховувати багато факторів.
Наприклад, досвід роботи. Наскільки чітко ви уявляєте обсяг майбутніх робіт? Чи робили раніше щось подібне? Зрозуміло, що чим більший досвід, тим швидше робота буде виконана.
Чималу роль визначенні термінів грає грамотно складене технічне завдання. З цим у нашій сфері справи дуже туго. Часто клієнт сам не знає, чого хоче, тому я раджу витратити зайвий день-два, але добитися від клієнта чіткого уявлення про бажаний результат. Важливо, щоб це уявлення було обопільним. І лише після цього можна починати обумовлювати суму та терміни.
Також завжди закладайте ризики. Початківцям я рекомендую передбачувані терміни виконання множити на два. Адже краще здати проект раніше термінів і вирости як фахівець в очах замовника, ніж здати пізніше та зіпсувати свою репутацію.
Підвищити Зменшити
Загальна рекомендація - розробнику необхідно навчитися правильно декомпозувати завдання, завжди шукати можливе підводне каміння, спиратися на власний досвід і не забувати вчасно попереджати замовників та колег, якщо в названі терміни завдання вирішити не виходить.
Вибудувати чіткий план набагато складніше, ніж визначити термін виконання окремо взятої задачі. При цьому важливо не лише здати проект вчасно, а й зробити так, щоб розроблена вами система коректно вирішувала завдання бізнесу. Тут ІТ-командам допомагають різні методології розробки ПЗ: від RUP та MSF до SCRUM та інших Agile-форматів. Вибір інструментів дуже великий, і багато наших замовників хочуть заздалегідь розуміти, як ми з ними працюватимемо в проекті, яких принципів ми дотримуємося.
До речі, тема Agile сьогодні стає близькою і бізнесу, і навіть в окремих проектах держсектору, оскільки принципи цієї методології дозволяють реалізовувати проекти дуже швидко, керуючи очікуваннями замовника на кожній ітерації. Наприклад, в Agile-команді практично не буває тривалих обговорень із замовником. Забудьте про десятки сторінок з описом непотрібних технічних деталей, наприклад, про швидкість появи списку, що випадає. Дайте замовнику можливість спробувати проміжну версію системи, тоді розуміти один одного вам стане набагато простіше.
Agile-команда все планує разом і визначає оптимальний рівень трудовитрат, які знадобляться для вирішення того чи іншого завдання. Наприклад, одна з технік називається Poker Planning, де кожен учасник анонімно дає свою оцінку необхідних трудовитрат з конкретного завдання. Після цього команда визначає середню вагу завдання в story points або людино-годинниках та розподіляє справи за принципом «кому що подобається». При цьому щодня команда збирається на 15-хвилинний мітинг, коли кожен за пару хвилин розповідає про статуси своїх поточних завдань, у тому числі повідомляє про труднощі. Виявлену проблему команда швидко усуває, тому замовник дивиться на черговий етап роботи програміста максимально оперативно. Розробники не затягують з термінами виконання завдань через небажання зайвий раз смикати команду або марних спроб розібратися самостійно, вбиваючи дорогоцінний час. До речі, на таких міні-статусах у розробників виникає бажання проявити себе з кращого боку, показати, що ти відповідально підходиш до роботи. Це реально мотивує та самодисциплінує.
(час від роботи не стає підтримкою до першого моменту, вона починає виконання на ресурси); зведення до мінімуму затримкиабо час відповіді(час від роботи стає включено доти, доки не буде завершено у разі періодичної діяльності, або доки система не відповідає і руками першого виходу користувача у разі інтерактивної діяльності); або максимізація справедливості(рівна кількість часу процесора для кожного процесу, або у більш загальному плані відповідних моментів часу відповідно до пріоритету та робочого навантаження кожного процесу). На практиці ці цілі часто суперечать (наприклад, пропускна здатність порівняно із затримкою), таким чином, планувальник здійснюватиме відповідний компроміс. Перевага вимірюється якоюсь однією з проблем, згаданих вище, залежно від потреб та завдань користувача.
OS / 360 та наступники
AIX
В AIX версії 4 є три можливі значення для політики планування потоків:
- По-перше, перший вийшов: Після того, як нитка з цією політикою запланована, то виконується до завершення, якщо вона не заблокована, вона добровільно поступається управлінням процесором, або з більш високим пріоритетом нитки стає диспетчеризація. Тільки із фіксованим пріоритетом потоки можуть мати політику планування FIFO.
- Round Robin: Це схоже на AIX Version 3 планувальника схеми циклічному на основі 10мс тимчасових зрізів. Коли потік РР має контроль наприкінці часового інтервалу, він переміщається у хвіст черги ниток із таким самим пріоритетом. Лише із фіксованим пріоритетом потоки можуть мати політику планування Round Robin.
- ІНШЕ: Ця політика визначається POSIX1003.4a в реалізації. В AIX версії 4, ця політика визначаються як еквівалент RR, за винятком того, що він відноситься до різьблення з не фіксованим пріоритетом. Перерахунок значення пріоритету запущеного потоку на кожне переривання означає, що нитка може втратити контроль, тому що його значення пріоритету піднялося вище, ніж інша нитка. Це поведінка AIX Version 3.
Нитки в першу чергу цікавий для додатків, які в даний час складаються з декількох асинхронних процесів. Ці програми можуть накласти легке навантаження на систему, якщо перетворюється на багатопотокову структуру.
Версією попереднього алгоритму з перемиканнями є алгоритм найменшого часу виконання. Відповідно до цього алгоритму планувальник кожен раз вибирає процес з найменшим часом виконання. І тут також необхідно заздалегідь знати час виконання завдань. Коли надходить нове завдання, її повний час виконання порівнюється з часом виконання поточного завдання. Якщо час виконання нового завдання менший, поточний процес зупиняється і керування передається новим завданням. Ця схема дозволяє швидко обслуговувати короткі запити.
Трирівневе планування
Системи пакетної обробки дозволяють реалізувати трирівневе планування, як показано малюнку. У міру надходження в систему нові завдання спочатку поміщаються в чергу, що зберігається на диску. Впускний планувальник доступу вибирає завдання та передає його системі. Інші завдання залишаються в черзі.
Як тільки завдання потрапило в систему, для нього буде створено відповідний процес, і він може відразу розпочати боротьбу за доступ до процесора. Тим не менш можлива ситуація, коли процесів занадто багато і всі вони в пам'яті не поміщаються, тоді деякі з них будуть вивантажені на диск. Другий рівень планування визначає, які можна зберігати у пам'яті, які - на диску. Цим займається планувальник пам'яті .
Планувальник пам'яті періодично переглядає процеси на диску, щоб вирішити, який з них перемістити в пам'ять. Серед критеріїв, що використовуються планувальником, є:
1. Скільки часу пройшло з того часу, як процес було вивантажено на диск або завантажено з диска?
2. Скільки часу процес уже використав процесор?
3. Який розмір процесу (малі процеси не заважають)?
4. Яка важливість процесу?
Третій рівень планування відповідає за доступ процесів, що перебувають у стані готовності, до процесора. Коли йдеться про «планувальника», зазвичай мається на увазі саме планувальник процесора . Цим планувальником використовується будь-який алгоритм, що підходить до ситуації, як з перериванням, так і без. Деякі з цих алгоритмів ми вже розглянули, з іншими ще ознайомимося.
Планування у інтерактивних системах.
Циклічне планування.
Одним з найстаріших, найпростіших, справедливих і найчастіше використовуваних є алгоритм циклічного планування. Кожен процес надає деякий інтервал часу процесора, так званий квант часу. Якщо до кінця кванта часу процес все ще працює, він переривається, а керування передається іншому процесу. Вочевидь, якщо процес блокується чи припиняє роботу раніше, перехід управління відбувається у цей час. Реалізація циклічного планування проста. Планувальнику потрібно лише підтримувати список процесів у стані готовності. Коли процес вичерпав свій ліміт часу, він вирушає до кінця списку.
Єдиним цікавим моментом цього алгоритму є довжина кванту. Перемикання з одного процесу на інший займає деякий час - необхідно зберегти та завантажити регістри та карти пам'яті, оновити таблиці та списки, зберегти та перезавантажити кеш пам'яті тощо. Висновок можна сформулювати наступним чином: занадто малий квант призведе до частого перемикання процесів та невеликий ефективності, але дуже великий квант може призвести до повільного реагування на короткі інтерактивні запити. Значення кванта близько 20-50 мс часто є розумним компромісом.
Пріоритетне планування.
У циклічному алгоритмі планування є важливе припущення у тому, що це процеси рівнозначні. У ситуації комп'ютера з великою кількістю користувачів це може бути негаразд. Наприклад, в університеті насамперед мають обслуговуватись декани, потім професори, секретарі, прибиральниці і лише потім студенти. Необхідність брати до уваги подібні зовнішні фактори призводить до пріоритетного планування. Основна ідея проста: кожному процесу надається пріоритет, і управління передається готовому до роботи процесу з найвищим пріоритетом.
Декілька черг.
Один з перших пріоритетних планувальників був реалізований в системі CTSS (compatible time-shared system - сумісна система з поділом часу). Кожне перемикання означало вивантаження поточного процесу на диск
та зчитування нового процесу з диска. Розробники CTSS швидко зрозуміли, що ефективність буде вищою, якщо процесам, обмеженим можливостями процесора, виділяти більший квант часу, ніж якщо надавати їм невеликі кванти, але часто. З одного боку, це зменшить кількість перекачування з пам'яті на диск, а з іншого - призведе до погіршення часу відгуку, як ми вже бачили.
В результаті було розроблено рішення із класами пріоритетів. Процесам класу з вищим пріоритетом виділявся один квант, процесам наступного класу - два кванти, наступного - чотири кванти і т. д. Коли процес використав весь відведений йому час, він переміщався на клас нижче.
Як приклад, розглянемо процес, якому необхідно проводити обчислення протягом 100 квантів. Спочатку йому буде надано один квант, потім його перекачають на диск. Наступного разу йому дістанеться 2 кванти, потім 4, 8,16, 32, 64, хоча з 64 він використовує лише 37. У цьому випадку знадобиться всього 7 перекачування (включаючи початкове завантаження) замість 100, які знадобилися б при використанні циклічного алгоритму. Крім цього, у міру занурення в черзі пріоритетів процес все рідше запускатиметься, надаючи процесор більш коротким процесам.
"Найкоротший процес - наступний"
Оскільки алгоритм «Найкоротша задача – перше» мінімізує середній оборотний час у системах пакетної обробки, хотілося б використовувати його і в інтерактивних системах. Певною мірою це можливо. Інтерактивні процеси найчастіше дотримуються схеми «очікування команди, виконання команди, очікування команди, виконання команди...» Якщо розглядати виконання кожної команди як окреме завдання, можна мінімізувати загальний середній час відгуку, запускаючи найкоротше завдання. Єдина проблема полягає
у тому, щоб зрозуміти, який із очікуваних процесів найкоротший.
Один з методів ґрунтується на оцінці довжини процесу, що базується на попередній поведінці процесу. При цьому запускається процес, у якого оцінений час найменший. Припустимо, що передбачуваний час виконання команди дорівнює Т 0 і час наступного запуску дорівнює Т 1 . Можна покращити оцінку часу, взявши зважену суму цих часів аТ 0 + (1 - а) Т 1 . Вибираючи відповідне значення, ми можемо змусити алгоритм оцінки швидко забувати про попередні запуски або, навпаки, пам'ятати про них протягом довгого часу. Взявши а = 1/2, ми отримаємо серію оцінок:
Т0, Т0/2+Т1/2, Т0/4+Т1/4+Т2/2, Т0/8+Т1/8+Т2/4+T3/2.
Після трьох запусків вага Т0 в оцінці зменшиться до 1/8.
Метод оцінки наступного значення серії через зважене середнє попереднього значення та попередньої оцінки часто називають старінням. Цей метод застосовується у багатьох ситуаціях, де необхідна оцінка за попередніми значеннями. Найпростіше реалізувати старіння при а = 1/2. На кожному кроці потрібно лише
додати до поточної оцінки нове значення і розділити суму навпіл (зсунувши праворуч на 1 біт).
Гарантоване планування.
Принципово іншим підходом до планування є надання користувачам реальних обіцянок і їх виконання. Ось одна обіцянка, яку легко вимовити і легко виконати: якщо разом з вами процесором користуються n користувачів, вам буде надано 1/n потужності процесора.
І в системі з одним користувачем і n запущеними процесорами кожному дістанеться 1/n циклів процесора.
Щоб виконати цю обіцянку, система повинна відстежувати розподіл процесора між процесами з моменту створення кожного процесу. Потім система розраховує кількість ресурсів процесора, на яке процес має право, наприклад, час з моменту створення, поділений на n. Тепер можна порахувати відношення часу, наданого процесу, до часу, який він має право. Отримане значення 0,5 означає, що процесу виділили лише половину належного, а 2,0 означає, що процесу дісталося вдвічі більше, ніж належить. Потім запускається процес, у якого це ставлення найменше, доки
воно не стане більшим, ніж у його найближчого сусіда.
Лотерейне планування.
В основі алгоритму лежить роздача процесам лотерейних квитків на доступ до різних ресурсів, у тому числі і процесора. Коли планувальнику необхідно ухвалити рішення, вибирається випадково лотерейний квиток, і його власник отримує доступ до ресурсу. Щодо доступу до процесора, «лотерея» може відбуватися 50 разів на секунду, і переможець отримує 20 мс часу процесора.
Більш важливим процесам можна роздати додаткові квитки, щоб збільшити можливість виграшу. Якщо всього 100 квитків та 20 з них знаходяться в одного процесу, то йому дістанеться 20% часу процесора. На відміну від пріоритетного планувальника, в якому дуже важко оцінити, що означає, скажімо, пріоритет 40, у лотерейному плануванні очевидно. Кожен процес отримає відсоток ресурсів, приблизно рівний відсотку наявних у нього квитків.
Лотерейне планування характеризується декількома цікавими властивостями. Наприклад, якщо під час створення процесу дістається кілька квитків, то вже у наступній лотереї його шанси на виграш пропорційні кількості квитків.
Взаємодіючі процеси можуть за необхідності обмінюватись квитками. Так, якщо клієнтський процес надсилає повідомлення серверному процесу і потім блокується, він може передати всі свої квитки серверного процесу, щоб збільшити шанс запуску сервера. Коли серверний процес закінчує роботу, він може повернути усі квитки назад.
Справедливе планування.
Досі ми припускали, що кожен процес керується незалежно від того, хто його господар. Тому якщо користувач 1 створить 9 процесів, а користувач 2 - процес 1, то з використанням циклічного планування або у разі рівних пріоритетів користувачеві 1 дістанеться 90% процесора, а користувачеві 2 всього 10.
Щоб уникнути подібних ситуацій деякі системи звертають увагу на господаря процесу перед плануванням. У такій моделі кожному користувачеві дістається деяка частка процесора, і планувальник вибирає процес відповідно до цього факту. Якщо у нашому прикладі кожному з користувачів було
обіцяно по 50% процесора, то їм дістанеться по 50% процесора, незалежно від кількості процесів.
Планування у системах реального часу.
У системах реального часу істотну роль грає час. Найчастіше один або кілька зовнішніх фізичних пристроїв генерують вхідні сигнали, і комп'ютер повинен адекватно реагувати на них протягом заданого проміжку часу.
Системи реального часу поділяються на жорсткі системи реального часу що означає наявність жорстких термінів для кожного завдання (у них обов'язково треба укладатися), і гнучкі системи реального часу , У яких порушення тимчасового графіка небажані, але допустимі. В обох випадках реалізується поділ програми на кілька процесів, кожен з яких передбачуваний. Ці процеси найчастіше бувають короткими та завершують свою роботу протягом секунди. Коли з'являється зовнішній сигнал, саме планувальник повинен забезпечити дотримання графіка.
Зовнішні події, на які система має реагувати, можна поділити на періодичні(що виникають через регулярні інтервали часу) та неперіодичні(Виникають непередбачено). Можлива наявність кількох періодичних потоків подій, які система має обробляти. Залежно від часу, що витрачається на обробку кожної з подій, може виявитися, що система не може своєчасно обробити всі події.
Подібна інформація.
Все, про що було розказано в кількох попередніх розділах, більшою мірою орієнтувалося на проведення подальших досліджень з проблеми власного часу процесу та значно меншою мірою на практичні застосування. Заповнюючи цю прогалину, викладемо одне із методів обчислення свого часу процесу виходячи з статистичних даних про його еволюції.
Розглянемо одновимірний процес, стан якого характеризується речовинною змінною х. Припустимо, що спостереження за динамікою процесу виконуються в астрономічному часі t, так що t = t k та x = x k , k = 1, ..., п - фіксовані моменти спостереження та відповідні їм значення станів процесу. Існує безліч різноманітних математичних методів, що дозволяють побудувати такі криві, які або проходять через точки (t k , Xk), або найкращим o6 разом наближаються до них. Отримувані у своїй функції x = x(t) породжують, у свідомості враження, що аналізований процес залежить від механічного руху небесних тіл і, отже, його стан виражається через астрономічний час t. З таким висновком можна було б зважати; якщо не виникали б постійні труднощі під час спроб прогнозування подальшого перебігу процесу. Для значної частини різноманітних процесів, які мають прямого відношення до механічних рухів небесних тіл, одержувані з допомогою функції x = x(t) теоретичні передбачення поза інтервалу спостереження починають значно відхилятися від наступних експериментальних даних. Причину розбіжності теорії та експерименту зазвичай намагаються пояснити невдало підібраним методом обробки, проте істота справи може бути не в цьому.
Будь-який процес, що цікавить нас, протікає у Всесвіті. Він, безумовно, відчуває на собі вплив руху небесних тіл. Однак ця дія може виявитися «нежорсткою», невизначальною. Це, зокрема, може виявлятися у цьому, що у певних інтервалах течії астрономічного часу стан процесу залишається незмінним. Згадаймо у зв'язку з цим наведений раніше приклад із замкненим порожнім приміщенням, ізольованим від зовнішнього світу. Впустимо в приміщення лише одну живу муху. Протягом кількох днів зміни у стані системи «приміщення – муха» залежатимуть від переміщень мухи, оскільки змін у стані приміщення очікувати не доводиться. Разом про те важко уявити, що поведінка мухи жорстко пов'язані з перебігом астрономічного часу.
Зробивши такий довгий відступ, перейдемо до опису алгоритму для підрахунку свого часу процесу.
У цьому алгоритмі як натуральна міра часу вибирається одиниця обчислення локальних максимумів. Крім того, беруться до уваги можливі ділянки стаціонарного стану процесу, на яких, як зазначалося раніше, власний час зупиняється. Оскільки про ідентичність двох станів можна говорити лише в межах точності вимірів, то надалі використовується деяке позитивне число е - припустима помилка вимірів.
Отже, вхідними даними для алгоритму є натуральне число п, позитивне число 8, масиви (tk) і (x k ), k = 1, ..., п. Для зручності програмування алгоритм представлений у вигляді чотирьох модулів, що послідовно виконуються.
Модуль 1використовуючи дані п, е, t k), (x k), формує в загальному випадку нові масиви 7 = (7+ X=(X t) і цілком конкретний супутній масив Р = (?), де 1 = 1, ..., т, причому т<Сп. Основное назначение этого модуля -- выявление в массиве x k) последовательностей идентичных состояний процесса, сохранение первых элементов в таких последовательностях и удаление всех остальных и, наконец, уменьшение по определенному, правилу исходного интервала наблюдения от t до на сумму тех промежутков времени, в которых процесс протекает стационарно.
Модуль 1 включає наступні процедури:
р: = 1, т: = 0, k: = 1.
У п.п. 1, 2 вводяться лічильники з конкретними початковими значеннями:
У п.п. 3, 4 відбувається збільшення значень лічильників на 1.
Перевірити умову k^n. Якщо воно виконано, то перейти до п. 6, або до п. 11.
Перевірити нерівність x k --x k = е. Якщо вона має місце, перейти до п. 7, інакше до п. 9.
7. tii = ti - (tkl - tk), i = k1, ..., п.
Ця процедура означає, що якщо значення Xk і Xk 1 невиразні в межах помилки, всі моменти часу, починаючи з tk, зменшуються на величину tki-tk.
р = р. Повернутись до п. 4.
Tv = t k; X v: = x k; p = p v = v+l., тобто. відбувається формування елементів масивів Т, X, Р та присвоєння чергового значення v.
- 10. Прийняти (t k , ..., t n І (Xk, - Х п) як вихідні масиви розмірності п-k 1 + 1 і потім повернутися до п. 2.).
- 11. Видати на друк m, (T), (Х,) та (Р,), де i = l, ..., т. Кінець.
Пояснимо сенс елементів супутнього масиву Р. З попереднього тексту випливає, що значення pk дорівнює кількості тих елементів масиву (xk), які безпосередньо, слідують за, і відрізняються від x pi+ ...+, + менше ніж на е. Зазначимо також, що pi+...+pm=n.
Приклад 1. Дано: п = 20, (/*) = (2, 4, 7, 10, 12, 13, 15, 17, 20, 22, 24, 25,
- 27, 30, 32, 33, 34, 35, 36) і (х,) = (4, 4, 6, 6, 6, 3, 2, 4, 3, 3, 3, 2, 2, 4, 5 , 5,
- 5, 4, 3) див. рис. 9 а.
В результаті виконання модуля 1 виходить т = 11
(Г) = (2, 3, 4, 6, 8, 11, 1-2, 15, 17, 18, 19); (Х,) = (4, 6, 3, 2, 4, 3, 2, 4,5,4,3)
та (д.) = (2, 4, 1, 1, 1,3, 2, 1,3, 1, 1), див. рис. 9, б.
Модуль 2Вхідними даними йому є натуральне число т, і навіть масиви (7+ (X L ), = 1, ..., т. Цей модуль у масиві (TJ виявляє моменти часу [ТМ а ], 1 = 1 m (ml Приклад 2. Значення т, (Т ь ) та (X,] запозичуються з попереднього прикладу. Після виконання модуля 2 виходять ml = 3, m2 = 8, (Щ,) = (3, 8, 17), (Т*) = (3, 4, 6, 8, 11, 12, 15, 17), див. також рис. Модуль 3Вхідні дані ml, m2, (ТМ п), 1 = 1, ..., ml, (Г *), / 2 = 1, ..., гп2. Цей модуль призначений для побудови масиву (т(-г) за формулою Де ТБ 6 [ТМп, TMn+i] Змінна т є свій час, що породжується зміною змінної х. Його натуральною мірою є одиниця обчислення локальних максимумів. Приклад 3. Вихідні дані для Т 2) ті, що значень ml, m2 ITM, і в прикладі 2. . Після відповідних обчислень отримаємо Ы = (0; 0,2; 0,6; 1;
1,33; 1,78; 2). Модуль 4.Формує видачу результатів шляхом встановлення відповідності між значеннями т та елементами х із масиву (xk). Приклад 4. На основі даних прикладів 2 та 3 видається наступний результат, див. рис. 9, в: т: 0; 0,2; 0,6; 1; 1,33; 1,44; х: 6; 3; 2; 4; 3Т 02; Таким чином, розглянутий алгоритм дозволяє виробити поняття власного часу процесу на основі зафіксованої астрономічної шкалою часу інформації про зміну стану процесу. Цілком зрозуміло, що можна скористатися й іншими алгоритмами, заснованими, наприклад, на обчисленні послідовності локальних мінімумів або змішаної послідовності, що складається з локальних максимумів і мінімумів. При обробці експериментальних даних слід, ймовірно, випробовувати різні варіанти. Якщо з будь-яких причин експериментатор зупинив свій вибір на одному з конкретних власних часів і отримав при цьому масиви (т4 і (xk), то на наступному етапі йому слід скористатися якимись математичними методами для апроксимації експериментальних точок (т*, х) деякою наближеною світовою лінією процесу х = х(т) Екстраполюючи цю лінію за межі вихідного проміжку спостережень, він може видавати прогнози про подальше протікання процесу. Цікаво згадати про обчислювальний експеримент, що призначався для оцінки перспективності застосування запропонованого алгоритму. Як експериментальний матеріал були обрані дані про річні стоки нар. Вахш (Таджикистан) протягом 40 попередніх років. За цей же період були взяті відомості про динаміку числа Вольфа - найбільш вживаного інтегрального індексу сонячної активності. Останнє було покладено основою розробки свого часу процесу сонячної активності. До нового часу було перетворено інформацію про витрати нар. Вахш і потім на проміжку спостереження видана теоретична залежність витрати води як функції від часу сонячної активності. Характерна особливість отриманого графіка - майже періодична поведінка максимальних та мінімальних витрат. Величини витрат, однак, не залишаються незмінними. Вступ Мета практикуму з організації виробництва – розширити і поглибити теоретичні знання, прищепити необхідні навички для вирішення задач, що найчастіше зустрічаються на практиці, з питань організації та планування виробництва. У практикум включені завдання з основних розділів курсу. На початку кожної теми представлені короткі методичні вказівки та теоретичні відомості, типові завдання з рішеннями та завдання для самостійного вирішення. Наявність у кожній темі методичних вказівок та коротких теоретичних відомостей дозволяє використати цей практикум при заочній формі навчання. Розрахунок тривалості виробничого циклу Як показник ефективності виробничого процесу служить тривалість виробничого циклу. Виробничий цикл- Період перебування предметів праці в процесі виробництва з моменту запуску сировини і до моменту випуску готової продукції. Виробничий цикл складається з робочого часу,протягом якого витрачається робоча праця, та часу перерв. Перерви залежно від причин, що їх викликали, можуть бути підрозділені: 1) на природнічи технологічні – вони зумовлені природою продукту; 2) організаційні(перерви між змінами). Тривалість виробничого циклу складається з таких складових: Т циклу = tтих + tїсть + tтр + tк.к. + tм.о. + tм.ц. де tтих- Час технологічних операцій; t їсть -час природних процесів (сушіння, охолодження тощо); t тр –час транспортування предметів праці; t к.к. -час контролю за якістю; t м.о –час міжопераційного пролягання; t м.ц. -час пролягання на міжцехових складах; (tтри tк.к. можна поєднати з tм.о). Розрахунок тривалості виробничого циклу залежить від типу виробництва. У масовому виробництві тривалість виробничого циклу визначається часом перебування виробу на потоці, тобто. Т циклу = t·М, де tв- Такт випуску; М- Кількість робочих місць. Під тактом випускуслід розуміти проміжок часу між випуском одного виробу, що виготовляється, і наступного за ним виробу. Такт випуску визначається за формулою t = Т еф / В, де Теф– ефективний фонд часу робітника за розрахунковий період (зміну, добу, рік); В- Обсяг випуску за той же період (в натуральних одиницях). Приклад: Т см = 8:00 = 480 хв; Т пер = 30 хв; → Теф = 480 - - 30 = 450 хв. У = 225 шт; → tв = 450/225 = 2 хв. У серійному виробництві, де обробка ведеться партіями, тривалість технологічного циклу визначається не так на одиницю продукції, але в всю партію. Причому залежно від способу запуску партії у виробництво ми отримуємо різну тривалість циклу. Існує три способи руху виробів у виробництві: послідовний, паралельний та змішаний (послідовно-паралельний). I. При послідовномуПереміщення деталей кожна наступна операція починається тільки після того, як закінчиться попередня. Тривалість циклу при послідовному русі деталей дорівнюватиме: де n
- Кількість деталей оброблюваної партії; t штi- штучна норма часу на операцію; C i- Число робочих місць на i-ї операції; m- Число операцій технологічного процесу. Дано партію виробів, що складається з 5 штук. Партія пропускається послідовно через чотири операції; тривалість першої операції – 10 хв, другої – 20 хв, третьої – 10 хв, четвертої – 30 хв (рис. 1). Малюнок 1 Тциклу = Тпосл = 5 · (10 +20 +10 +30) = 350 хв. Послідовний спосіб руху деталей має ту перевагу, що забезпечує роботу обладнання без простоїв. Але його недолік у тому, що тривалість виробничого циклу у разі найбільша. Крім того, створюються значні запаси деталей у робочих місць, що потребує додаткових виробничих площ. II. При паралельномуРуху партії окремі деталі не затримують у робочих місць, а поштучно передають на наступну операцію негайно, не чекаючи, коли закінчиться обробка всієї партії. Таким чином, при паралельному русі партії деталей кожному робочому місці одночасно проводяться різні операції над різними деталями однієї й тієї партії. Тривалість обробки партії при паралельному русі виробів різко скорочується: де n n– кількість деталей у передавальної партії(транспортної партії), тобто. кількість виробів, що одночасно передаються від однієї операції до іншої; Дл. - Найбільш тривалий операційний цикл. При паралельному запуску партії виробів обробка деталей всієї партії ведеться безупинно лише тих робочих місцях, де довгі операції йдуть за короткими. Тоді, коли короткі операції слідують за довгими, тобто. Найбільш тривалими (у прикладі – третя операція), виконання цих операцій відбувається безперервно, тобто. простоює обладнання. Тут партію деталей не можна обробляти відразу, без затримок, оскільки цього дозволяє попередня (довга) операція. У нашому прикладі: n= 5, t 1 = 10; t 2 = 20; t 3 = 10; t 4 = 30; з= 1. Тпар = 1 · (10 +20 +10 +30) + (5-1) · 30 = 70 +120 = 190 хв. Розглянемо схему паралельного руху деталей (рис. 2): Малюнок 2 III. Щоб ліквідувати перерви в обробці окремих деталей партії на всіх операціях застосовують паралельно-послідовнийабо змішанийспосіб запуску, при якому деталі (після їх обробки) передаються на наступну операцію поштучно, або у вигляді транспортних заділів (по кілька штук) з таким розрахунком, щоб виконання операцій не переривалося на жодному робочому місці. У змішаному методі від послідовного береться безперервність обробки, як від паралельного – перехід деталі від операції до операції відразу після її обробки. При змішаному способі запуску у виробництво тривалість циклу визначається за формулою де кор. - Найкоротший операційний цикл (з кожної пари суміжних операцій); m-1 –
кількість суміщень. Якщо наступна операція є більш тривалою, ніж попередня, або дорівнює їй часу, то запуск на цю операцію проводиться поштучно, відразу після обробки першої деталі на попередній операції. Якщо, навпаки, наступна операція є коротшою, ніж попередня, то при поштучної передачі виникають перерви. Щоб їх не допустити, необхідно накопичити транспортний заділ такого обсягу, який є достатнім для забезпечення роботи на подальшій операції. Щоб практично знайти цю точку на графіку, необхідно передати останню деталь партії та відкласти праворуч тривалість її виконання. Час обробки решти деталей партії відкладається на графіку вліво. Початок обробки першої деталі показує той момент, коли транспортний заробіток з попередньої операції повинен бути переданий на цю операцію. Якщо суміжні операції є однаковими за тривалістю, то коротку чи довгу приймається лише одне з них (рис. 3). Малюнок 3 Тпосл-пар = 5 · (10 +20 +10 +30) - (5-1) · (10 +10 +10) = 350-120 = 230 хв. Основними шляхами скорочення тривалості виробничого циклу є: 1) Зниження трудомісткості виготовлення продукції за рахунок вдосконалення технологічності конструкції, що виготовляється, використання ЕОМ, впровадження передових технологічних процесів. 2) Раціональна організація трудових процесів, влаштування та обслуговування робочих місць на основі спеціалізації та кооперування, широкої механізації та автоматизації виробництва. 3) Скорочення різних запланованих та непланованих перерв на роботі на основі раціонального використання принципів наукової організації виробничого процесу. 4) Прискорення перебігу реакцій внаслідок підвищення тиску, температур, переходу на безперервний процес тощо. 5) Удосконалення процесів транспортування, складування та контролю та поєднання їх за часом з процесом обробки та складання. Скорочення тривалості виробничого циклу одна із серйозних завдань організації виробництва, т.к. позначається на оборотності оборотних засобів, зниженні витрат праці, зменшенні складських приміщень, потреби у транспорті тощо. Завдання 1 Визначити тривалість циклу обробки 50 деталей при послідовному, паралельному та послідовно-паралельному видах руху в процесі виробництва. Процес обробки деталей складається з п'яти операцій, тривалість яких відповідно становить, хв: t 1 =2; t 2 =3; t 3 =4; t 4 =1; t 5 =3. Друга операція виконується на двох верстатах, а кожна з решти на одному. Розмір передавальної партії 4 штуки. 2 Визначити тривалість циклу обробки 50 деталей при послідовному, паралельному та послідовно-паралельному видах руху в процесі виробництва. Процес обробки деталей складається з чотирьох операцій, тривалість яких відповідно становить, хв: t 1 =1; t 2 =4; t 3 =2; t 4 =6. Четверта операція виконується на двох верстатах, а кожна з решти на одному. Розмір передавальної партії – 5 штук. 3 Партія деталей 200 штук обробляється при паралельно-послідовному русі її в процесі виробництва. Процес обробки деталей складається з шести операцій, тривалість яких відповідно становить, хв: t 1 =8; t 2 =3; t 3 =27; t 4 =6; t 5 =4; t 6 = 20. Третя операція виконується на трьох верстатах, шоста на двох, а кожна з решти операцій – на одному верстаті. Визначити, як зміниться тривалість циклу обробки партії деталей, якщо паралельно-послідовний варіант руху на виробництві замінити паралельним. Розмір передавальної партії – 20 штук. 4 Партія деталей 300 штук обробляється при паралельно-послідовному русі її в процесі виробництва. Процес обробки деталей складається з семи операцій, тривалість яких відповідно становить, хв: t 1 =4; t 2 =5; t 3 =7; t 4 =3; t 5 =4; t 6 =5; t 7 =6. Кожна операція виконується одному верстаті. Передавальна партія – 30 штук. В результаті покращення технології виробництва тривалість третьої операції скоротилася на 3 хв, сьомий – на 2 хв. Визначити, як змінюється цикл обробки деталей. 5 Дано партію заготовок, що складається з 5 штук. Партія пропускається через 4 операції: тривалість першої – 10 хв, другої – 20 хв, третьої – 10 хв, четвертої – 30 хв. Визначити тривалість циклу аналітичним та графічним способами при послідовному русі. 6 Дана партія заготовок, що складається із чотирьох штук. Партія пропускається через 4 операції: тривалість першої – 5 хв, другої – 10 хв, третьої – 5 хв, четвертої – 15 хв. Визначити тривалість циклу аналітичним та графічним способами при паралельному русі. 7 Дано партію заготовок, що складається з 5 штук. Партія пропускається через 4 операції: тривалість першої – 10 хв, другої – 20 хв, третьої – 10 хв, четвертої – 30 хв. Визначити тривалість циклу аналітичним та графічним способами при послідовно-паралельному русі. 8 Визначити тривалість технологічного циклу обробки партії виробів із 180 шт. при паралельному та послідовному варіантах її руху. Побудувати графіки процесу обробки. Розмір передавальної партії – 30 прим. Норми часу та кількість робочих місць на операціях такі.
дл .
кор .
