Головна > Реалізація > Процес обчислення часу, що залишився. Найменший час виконання, що залишився. технічний директор центру інноваційних технологій та рішень «Інфосистеми Джет»


Процес обчислення часу, що залишився. Найменший час виконання, що залишився. технічний директор центру інноваційних технологій та рішень «Інфосистеми Джет»




Версією попереднього алгоритму з перемиканнями є алгоритм найменшого часу виконання. Відповідно до цього алгоритму планувальник кожен раз вибирає процес з найменшим часом виконання. І тут також необхідно заздалегідь знати час виконання завдань. Коли надходить нове завдання, її повний час виконання порівнюється з часом виконання поточного завдання. Якщо час виконання нового завдання менший, поточний процес припиняється і керування передається новим завданням. Ця схема дозволяє швидко обслуговувати короткі запити.

Трирівневе планування

Системи пакетної обробки дозволяють реалізувати трирівневе планування, як показано на малюнку. У міру надходження в систему нові завдання спочатку поміщаються в чергу, що зберігається на диску. Впускний планувальник доступу вибирає завдання та передає його системі. Інші завдання залишаються в черзі.

Як тільки завдання потрапило в систему, для нього буде створено відповідний процес, і він може відразу розпочати боротьбу за доступ до процесора. Тим не менш можлива ситуація, коли процесів занадто багато і всі вони в пам'яті не поміщаються, тоді деякі з них будуть вивантажені на диск. Другий рівень планування визначає, які можна зберігати у пам'яті, які - на диску. Цим займається планувальник пам'яті .

Планувальник пам'яті періодично переглядає процеси на диску, щоб вирішити, який з них перемістити в пам'ять. Серед критеріїв, що використовуються планувальником, є такі:

1. Скільки часу пройшло з того часу, як процес було вивантажено на диск або завантажено з диска?

2. Скільки часу процес використовував процесор?

3. Який обсяг процесу (маленькі процеси не заважають)?

4. Яка важливість процесу?

Третій рівень планування відповідає за доступ процесів, що перебувають у стані готовності, до процесора. Коли йдеться про «планувальника», зазвичай мається на увазі саме планувальник процесора . Цим планувальником використовується будь-який відповідний ситуації алгоритм, як із перериванням, і без. Деякі з цих алгоритмів ми вже розглянули, з іншими ще ознайомимося.

Планування у інтерактивних системах.

Циклічне планування.

Однією з найстаріших, простих, справедливих і найчастіше використовуваних є алгоритм циклічного планування. p align="justify"> Кожному процесу надається деякий інтервал часу процесора, так званий квант часу. Якщо до кінця кванта часу процес все ще працює, він переривається, а керування передається іншому процесу. Вочевидь, якщо процес блокується чи припиняє роботу раніше, перехід управління відбувається у цей момент. Реалізація циклічного планування проста. Планувальнику потрібно лише підтримувати список процесів у стані готовності. Коли процес вичерпав свій ліміт часу, він вирушає до кінця списку.

Єдиним цікавим моментом цього алгоритму є довжина кванту. Перемикання з одного процесу на інший займає деякий час - необхідно зберегти та завантажити регістри та карти пам'яті, оновити таблиці та списки, зберегти та перезавантажити кеш пам'яті тощо. Висновок можна сформулювати наступним чином: занадто малий квант призведе до частого перемикання процесів ефективності, але надто великий квант може призвести до повільного реагування на короткі інтерактивні запити. Значення кванта близько 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% процесора, незалежно від кількості процесів.

Планування у системах реального часу.

У системах реального часу істотну роль грає час. Найчастіше одне або кілька зовнішніх фізичних пристроїв генерують вхідні сигнали, і комп'ютер повинен адекватно реагувати на них протягом заданого проміжку часу.

Системи реального часу поділяються на жорсткі системи реального часу що означає наявність жорстких термінів для кожного завдання (у них обов'язково треба укладатися), і гнучкі системи реального часу , У яких порушення тимчасового графіка небажані, але допустимі. В обох випадках реалізується поділ програми на кілька процесів, кожен з яких передбачуваний. Ці процеси найчастіше бувають короткими та завершують свою роботу протягом секунди. Коли з'являється зовнішній сигнал, планувальник повинен забезпечити дотримання графіка.

Зовнішні події, на які система має реагувати, можна поділити на періодичні(що виникають через регулярні інтервали часу) та неперіодичні(що виникають непередбачувано). Можлива наявність кількох періодичних потоків подій, які система має обробляти. Залежно від часу, що витрачається на обробку кожної з подій, може виявитися, що система не в змозі своєчасно опрацювати всі події.


Подібна інформація.


(час від роботи стає включено доти, доки не буде завершено у разі періодичної діяльності, або доки система не відповідає і руками першого виходу користувача у разі інтерактивної діяльності); або максимізація справедливості(рівна кількість часу процесора для кожного процесу, або у більш загальному плані відповідних моментів часу відповідно до пріоритету та робочого навантаження кожного процесу). На практиці ці цілі часто суперечать (наприклад, пропускна здатність порівняно із затримкою), таким чином, планувальник здійснюватиме відповідний компроміс. Перевага вимірюється якоюсь однією з проблем, згаданих вище, залежно від потреб та завдань користувача.

OS/360 та наступники

AIX

В AIX версії 4 є три можливі значення для політики планування потоків:

  • По-перше, перший вийшов: Після того, як нитка з цією політикою запланована, то виконується до завершення, якщо вона не заблокована, вона добровільно поступається управлінням процесором, або з більш високим пріоритетом нитки стає диспетчеризація. Лише із фіксованим пріоритетом потоки можуть мати політику планування FIFO.
  • Round Robin: Це схоже на AIX Version 3 планувальника схеми циклічному на основі 10мс тимчасових зрізів. Коли потік РР має контроль наприкінці часового інтервалу, він переміщається у хвіст черги ниток із таким самим пріоритетом. Лише із фіксованим пріоритетом потоки можуть мати політику планування Round Robin.
  • ІНШЕ: Ця політика визначається POSIX1003.4a в реалізації. В AIX версії 4, ця політика визначаються як еквівалент RR, за винятком того, що він відноситься до різьблення з не фіксованим пріоритетом. Перерахунок значення пріоритету запущеного потоку на кожне переривання означає, що нитка може втратити контроль, тому що його значення пріоритету піднялося вище, ніж інша нитка. Це поведінка AIX Version 3.

Нитки в першу чергу цікаві для додатків, які в даний час складаються з декількох асинхронних процесів. Ці програми можуть накласти легке навантаження на систему, якщо перетворюється на багатопотокову структуру.

AIX 5 реалізує такі політики планування: FIFO, круговий та справедливий круговий. Політика FIFO складається з трьох різних реалізацій: ФІФО, FIFO2 та FIFO3. Кругла політика малиновки називається SCHED_RR в AIX і справедливий кругової називають SCHED_OTHER.

Linux

Linux 2.4

Brain Fuck Scheduler (BFS), також створений Колівас, є альтернативою CFS.

FreeBSD

FreeBSD використовує багаторівневу чергу зворотного зв'язку з пріоритетами в діапазоні 0-255. 0-63 зарезервовані для переривань, 64-127 для верхньої половини ядра, 128-159 у режимі реального часу потоків користувачів, 160-223 для поділу часу потоків користувачів, та 224-255 для пустих ниток користувача. Крім того, як Linux, він використовує активне налаштування черги, але він також має пусту чергу.

Найчастіше розробники, особливо недосвідчені, губляться, коли просять позначити терміни виконання завдань. Проте вміння планувати - дуже корисна і потрібна навичка, яка допомагає не тільки в роботі, а й у житті. Ми вирішили дізнатися в експертів, як навчитися правильно планувати та складати проекти вчасно.

Короткі висновки можна побачити наприкінці статті.

Розробнику зазвичай потрібно врахувати відразу кілька параметрів, щоб оцінити час виконання завдання:

  1. Досвід виконання таких завдань та роботи з даним технологічним стеком. Якщо потрібно робити щось принципово нове, потрібно особливо обережним з оцінкою.
  2. Досвід роботи з цим клієнтом. Знаючи замовника, можна приблизно передбачити деякі додаткові вимоги та обсяг правок.
  3. Якість коду, з яким має працювати. Це найвпливовіший фактор, через який все може сильно затягнутися і взагалі піти не за планом. Якщо у проекті є тести, скрізь лише явні залежності та функціональність добре ізольована, все не так страшно. Набагато гірше, якщо ви маєте справу з легасом без тестів або з кодом, перенасиченим неявними залежностями. Ускладнювати справу можуть також такі речі, як магічні функції (коли за кодом важко побачити кінцевий стек викликів) і дублювання коду (коли для зміни будь-якої функціональності потрібно правити кілька незалежних ділянок).

Щоб навчитися адекватно оцінювати термін роботи, потрібно постійно практикуватися. На початку своєї роботи я чинив саме так: оцінював час на виконання будь-якого вхідного завдання, навіть якщо цього ніхто не вимагав, а потім дивився, наскільки точно вдалося потрапити до своєї оцінки. У процесі виконання завдання наголошував, які дії займають більше часу. Якщо щось сильно збільшувало термін, запам'ятовував цей момент та враховував його у наступних оцінках.

До об'єктивної оцінки часу, потрібного на роботу, слід додавати невеликий запас покриття форс-мажорних ситуацій. Його часто оцінюють у відсотках від виконання основного завдання, але у всіх він різний: хтось додає 20% часу, хтось – 10%, а хтось – 50%.

Корисно також аналізувати причини зривів термінів після кожного серйозного порушення дедлайну. Якщо забракло кваліфікації, треба попрацювати над своїми слабкими місцями. Якщо проблема була організаційною – зрозуміти, що завадило нормально працювати.

Підвищити Зменшити

, технічний директор центру інноваційних технологій та рішень «Інфосистеми Джет»

Методикам оцінки трудомісткості проекту, включаючи тривалість робіт та окремих завдань, присвячено велику кількість статей. Однак досі це є причиною конфліктів як усередині проектної команди, так і при спілкуванні із замовником.

Основний помічник в оцінці – досвід. Спробуйте якось зіставити нове завдання із вже зробленими. Якщо ви робите звіт, подивіться, скільки часу зайняв схожий звіт у минулому. Якщо ви робите щось нове, спробуйте розбити на певні частини та оцінити їх. Якщо завдання зовсім нова, виділіть час вивчення (ще краще - погодьте цей час із тим, хто ставить завдання).

Зверніть увагу на супутні етапи - якщо потрібно розробити сервіс, то в оцінку необхідно включити також і юніт-тестування (а може і не тільки юніт), певний час займе підготовка тестових даних. Слід продумати інтеграцію з іншими сервісами тощо. Закладіть час на виправлення дефектів, які ви знайдете самостійно або за допомогою тестувальників. Багато часу може витікати у «непомітні» завдання. Наприклад, є оцінка з розробки і є оцінка тестування, але передача артефакту на тестування може бути пов'язана з розгортанням стендів. Тому важливо подумки собі уявити весь процес, щоб нічого не проґавити.

Після визначення трудомісткості необхідно включити нові роботи в календар, не забувши про інші завдання та активності, що йдуть паралельно.

І не забувайте, що плани марні, але планування безцінне. Вчіться вчасно коригувати плани, тримати в курсі всіх зацікавлених та своєчасно ескалювати, щоб провалені терміни не виявилися ні для кого несподіванкою.

Підвищити Зменшити

Питання, на яке неможливо відповісти у короткій формі. Якби це було просто, то проблеми порушення термінів не було б.

Щоб зробити терміни закінчення розробки більш передбачуваними, треба спочатку зрозуміти причини, через які програмісти постійно помиляються.

Перша причина – більшість завдань, які робить програміст, є тією чи іншою мірою унікальними. Тобто, швидше за все, програміст робитиме подібне завдання вперше. Він недостатньо добре уявляє, скільки займе ця робота. Якщо це програміст із солідним досвідом і йому доводилося виконувати подібне завдання, його оцінка буде ближчою до реальності.

Вдамося до простої аналогії - якщо ви ніколи не копали канави, ви не можете точно сказати, скільки часу у вас займе викопати траншею 30 см завширшки, 60 см завглибшки і 20 метрів завдовжки. Якщо ви раніше копали, оцінка часу роботи у вас буде набагато ближчою до фактичної тривалості роботи.

Друга причина – програмісти за своєю природою оптимісти. Тобто, розглядаючи завдання, підбираючи для неї варіант реалізації, оцінюючи доробки, розробник очікує, що все працюватиме так, як він передбачає. І не думає про ті проблеми, які йому зустрінуться на шляху. Найчастіше він не може їх передбачати. Наприклад, є завдання, що програміст може реалізувати, використовуючи сторонню open-source програмну бібліотеку. На етапі оцінки він знайшов її в інтернеті, прочитав її опис – вона йому підходить. І навіть вірно оцінив обсяг своєї роботи, щоб вбудувати використання цієї бібліотеки. Але він зовсім не передбачив, що серед його програмного продукту в цій бібліотеці виникне помилка.

Розробнику доведеться не тільки вбудувати використання бібліотеки у свій код, але й виправити помилку в бібліотеці. А ще часто розробник не передбачає часу на виправлення своїх помилок. Як показує статистика, тестування та виправлення помилок може займати близько 50% від часу, що було витрачено на кодинг. Цифра залежить від кваліфікації розробника, оточення, використовуваних практик розробки (наприклад, юніт тести істотно скорочують цей час і підсумкова тривалість/трудомісткість завдання з розробки виходить менше).

Якщо повернутися до аналогії із землекопом, то землекоп не припускав, що в нього зламається лопата і доведеться витратити дві години на пошуки нового живця.

Третя причина – непередбачені вимоги. У жодній галузі матеріального виробництва, з якими так люблять порівнювати замовники розробку програмного забезпечення, немає такого потоку нових вимог. Уявіть собі пасаж землекопа, який викопав 19 метрів із 20 і почув від замовника побажання, щоб канава йшла не прямою, а змійкою з довжиною плеча 97 сантиметрів.

Як з усім цим боротися і як жити в умовах такої невизначеності? Зменшуючи невизначеність та закладаючи резерв часу.

Найпростіший спосіб привести свої очікування ближче до реальності – це використати жартівливе емпіричне правило «Пі». Отримавши оцінку від розробника (за термінами чи трудомісткості), треба помножити в число Пі (= 3,14159). Чим досвідченіший розробник робив оцінку, тим менше може бути цей коефіцієнт.

Обов'язковою є практика декомпозиції вихідної задачі до дрібних завдань розміром трохи більше 4 годин. Чим детальніше виконана декомпозиція, тим вищі шанси, що оцінка виявиться близькою до фактичної трудомісткості/тривалості.
Якщо повернутися до виділення резерву – цей час має бути виділено наприкінці проекту. Погана практика робити резерв і включати його для кожного завдання. Закон Паркінсона "Робота заповнює весь час, відпущений на неї" виконується неухильно.

Якщо підвести коротке «всього», то щоб правильно визначити терміни виконання роботи, корисні будуть такі дії:

  • виконати декомпозицію робіт, розбити завдання на якомога детальніші кроки;
  • провести прототипування;
  • обмежити реалізацію непередбачених раніше вимог. Це не означає, що їх не треба робити, але доцільно виділяти ці вимоги та погоджувати із замовником зміну термінів та вартості для їх реалізації;
  • врахувати час на стабілізацію рішення;
  • використовувати практики підвищення якості коду, наприклад, писати юніт тести;
  • закласти загальний резерв.

Ну, і пам'ятати, що якщо факт перевищує вашу оцінку на 30% - це дуже хороший результат.

Підвищити Зменшити

Для максимально точної оцінки потрібен досвід реальної розробки, причому саме в конкретної галузі. Але є й загальні правила, які допоможуть уникнути помилок у плануванні та проблем при здачі роботи замовнику. Я би описав ці правила так.

По-перше, потрібно зрозуміти завдання. Це начебто очевидно і не стосується безпосередньо оцінки термінів, але насправді це ключовий момент. Навіть у серйозних великих проектах одним із основних факторів невдачі та затягування термінів є проблема у визначенні вимог. У розробників-початківців, на жаль, це серйозна проблема - не читають ТЗ або читають і розуміють дуже вибірково (з десяти пунктів запам'ятали і виконали п'ять, а про решту згадали вже при здачі результату). Зрозуміло, що неправильно зрозуміле завдання неможливо правильно реалізувати вчасно.

Далі - оцінити час на розробку. Особливість програмування у цьому, що немає абсолютно однакових завдань. Це робить нашу роботу цікавішою, але оцінку термінів – складніше. Тут добре працює декомпозиція, тобто. поділ складної унікальної задачі на послідовність маленьких знайомих підзадач. А кожну з них уже можна оцінити в годиннику достатньо адекватно. Складемо оцінки підзадач - і отримаємо оцінку всього завдання.

Як правило, така оцінка включає лише витрати безпосередньо на кодування. Це, безумовно, найважливіша частина розробки, але не єдина (а часто - і найбільша). Повне виконання завдання включає ще читання і прояснення ТЗ, зустрічі з колегами або замовником, налагодження і тестування, складання документації, здачу результату (демонстрацію замовнику і можливі переробки за його зауваженнями). Скільки саме часу у вас піде на ці дії, підкаже лише досвід. Спочатку важливо, як мінімум, не забути їх врахувати в розрахунках, а приблизну оцінку часу можна запитати у більш досвідчених колег.

Отже, ми беремо оцінку трудовитрат на кодування, додаємо оцінку витрат на додаткові роботи - і отримуємо оцінку часу на виконання завдання. Але це ще не все! Потрібно позначити заплановану дату завершення завдання. Помилка буде просто взяти і розділити трудовитрати (у годинах) на 8 годин і додати до поточної дати. У реальній практиці розробник ніколи (ну гаразд, майже ніколи) не працює 100% часу над одним конкретним завданням. У вас обов'язково буде витрачати час на інші роботи - важливі, але не пов'язані безпосередньо з головною. Наприклад, допомога колегам, навчання, складання звітів тощо. Зазвичай, при плануванні вважають, що безпосередньо на роботу над поточним проектом йде 60-70% робочого часу. Додатково треба врахувати можливі затримки, які не дадуть вам безперервно працювати над завданням. Наприклад, якщо для цього вам потрібно взаємодіяти з іншими людьми (колегами, замовниками), то враховуйте їхню зайнятість, графік роботи тощо.

Ось основні правила, які, як на мене, допоможуть розробнику уникнути проблем в оцінці та дотриманні термінів. Крім цього, ключовим є накопичення власного досвіду як у реалізації завдань, так і в оцінці. Наприклад, дуже корисно після завершення завдання порівнювати свою початкову оцінку з фактичними термінами та робити висновки на майбутнє. І, звісно, ​​варто вивчити чужий досвід. Я б порекомендував на тему книги С. Макконнелла «Скільки коштує програмний проект» та С. Архіпенкова «Лекції з управління програмними проектами».

Підвищити Зменшити

При оцінці та плануванні термінів необхідно:

  1. Декомпозувати завдання до невеликих функціональних шматків таким чином, щоб було чітке розуміння скільки часу займе розробка кожного такого шматка.
  2. Паралельно з декомпозицією обов'язково виникатимуть додаткові питання щодо функціональності, яка не була описана у постановці завдання. Необхідно отримати відповіді такі питання, оскільки це безпосередньо стосується обсягу робіт і, отже, термінів.
  3. До підсумкової оцінки додати певний відсоток ризиків. Це визначається дослідним шляхом. Можна почати, наприклад, із ризиків розміром 10–15 %.
  4. Зрозуміти, скільки годин на день програміст готовий виділяти виконання завдання.
  5. Ділимо підсумкову оцінку на кількість годин, які виділяємо на день, та отримуємо кількість днів, необхідних на реалізацію.
  6. Орієнтуємось на календар та необхідну кількість днів на виконання. Зважаємо на вихідні та інші дні, коли програміст не зможе займатися завданням, а також дату початку робіт (не завжди розробник готовий взяти завдання в роботу в той же день). Таким чином, отримуємо дату початку та закінчення робіт.

Підвищити Зменшити

У нашій компанії планування завдань проходить кілька етапів. На стороні бізнесу ми формулюємо 5–6 стратегічних цілей на рік. Це високорівневі завдання, наприклад підвищити будь-який параметр на стільки відсотків. Далі різні підрозділи компанії формують бізнес-завдання на всі команди ІТ. Терміни цих завдань отримують первинну грубу оцінку, яка часто формується всіма учасниками команди - менеджером, аналітиком, розробником і тестувальником. Отримавши цю оцінку, бізнес пріоритезує завдання з огляду на стратегічні цілі компанії. У цьому допомагають наскрізні стратегічні цілі, з ними стає очевидним, що всі ми працюємо на якусь спільну справу, немає такої ситуації, коли хтось тягне лише у свій бік. З точно оцінених термінів завдань ми збираємо спринти. У деяких команд вони квартальні, у деяких – місячні. Кільком завданням, що за попередньою оцінкою потрапляють до наступного спринту, команди дають точну оцінку. Великі завдання розбиваються більш низькорівневі, кожну у тому числі відповідає конкретний виконавець, саме і дає точну оцінку.

На даному етапі важливо не забувати додавати запасу часу на виправлення багів, адже не помиляється тільки той, хто нічого не робить. Це чудово розуміють і Product Owner, і бізнес-замовники. При цьому необхідний запас часу має бути адекватним: ніхто не зрозуміє розробника, який поставить простому завданню надто довгий термін виконання, його попросять обґрунтувати рішення. Найскладніше - пояснити бізнесу, навіщо потрібен час на рефакторинг. Ми вдячні нашій компанії за те, що періодично нам це вдається, адже зрештою рефакторинг веде до полегшення інфраструктури та наведення порядку в коді, що підвищує стабільність системи та може суттєво прискорити розробку нових функцій.

Іноді помилки в оцінці все ж таки виникають. Відділу розробки у великих компаніяхз розвиненою інфраструктурою повністю уникнути цього, як на мене, неможливо. В даному випадку важливо, щоб розробник вчасно інформував про те, що відбувається, свого менеджера, а той, у свою чергу, встиг попередити бізнес і щось «переграти» в загальних планах компанії. У такому режимі працювати набагато правильніше, ніж судомно намагатися зробити за 3 дні те, що займає 5, а потім потонути у великій кількості помилок, що виникли через такий поспіх.

Підвищити Зменшити

Правильна відповідь на обидві частини питання [як навчитися правильно планувати та здавати проект вчасно - Ред.] - досвід. Інших шляхів «пізнання Дзена» немає. Відповідно до теорії прийняття рішень, скільки-небудь точні висновки можна будувати тільки на основі аналізу низки вже наявних даних. І чим більше цих даних – тим точніше підсумковий прогноз та оцінка.

Говорячи словами Герберта Шоу: «Досвід – це школа, в якій людина дізнається, яким дурнем вона була раніше». Звідси випливає досить простий висновок: якщо в програміста вже є досвід, що корелює з поставленим завданням - він може спиратися на нього, якщо ні - на досвід «колег по цеху».

Далі потрібно розуміти, що пряме планування термінів – завдання, з яким люди справляються дуже і дуже погано, особливо у розробці. Оцінюючи термінів здачі хорошої практикою вважається запровадження «поправочних коефіцієнтів» на вихідну оцінку. Ця метрика може коливатися в інтервалі від 1,5 до 3, залежно від досвіду розробника та сукупності ступенів невизначеності завдань, які вирішуються в рамках проекту.

Підвищити Зменшити

При визначенні термінів важливо враховувати багато чинників.

Наприклад, досвід роботи. Наскільки чітко ви уявляєте обсяг майбутніх робіт? Чи робили раніше щось подібне? Зрозуміло, що більше досвіду, то швидше робота буде виконано.

Чималу роль визначенні термінів грає грамотно складене технічне завдання. З цим у нашій сфері справи дуже туго. Часто клієнт сам не знає, чого хоче, тому я раджу витратити зайвий день-два, але добитися від клієнта чіткого уявлення про бажаний результат. Важливо, щоб ця вистава була обопільною. І тільки після цього можна починати обговорювати суму та строки.

Також завжди закладайте ризики. Початківцям я рекомендую передбачувані терміни виконання множити на два. Адже краще здати проект раніше за терміни і вирости як фахівець в очах замовника, ніж здати пізніше і зіпсувати свою репутацію.

Підвищити Зменшити

Загальна рекомендація - розробнику необхідно навчитися правильно декомпозувати завдання, завжди шукати можливе підводне каміння, спиратися на власний досвіді не забувати вчасно попереджати замовників та колег, якщо у названі терміни завдання вирішити не виходить.

Вибудувати чіткий план набагато складніше, ніж визначити термін виконання окремо взятої задачі. При цьому важливо не лише здати проект вчасно, а й зробити так, щоб розроблена вами система коректно вирішувала завдання бізнесу. Тут ІТ-командам допомагають різні методології розробки ПЗ: від RUP та MSF до SCRUM та інших Agile-форматів. Вибір інструментів дуже великий, і багато наших замовників хочуть заздалегідь розуміти, як ми з ними працюватимемо в проекті, яких принципів ми дотримуємося.

До речі, тема Agile сьогодні стає близькою і бізнесу, і навіть в окремих проектах держсектору, оскільки принципи цієї методології дозволяють реалізовувати проекти дуже швидко, керуючи очікуваннями замовника на кожній ітерації. Наприклад, в Agile-команді практично не буває тривалих обговорень із замовником. Забудьте про десятки сторінок з описом непотрібних технічних деталей, наприклад, про швидкість появи списку, що випадає. Дайте замовнику можливість спробувати проміжну версію системи, тоді розуміти один одного вам стане набагато простіше.

Agile-команда все планує разом і визначає оптимальний рівень трудовитрат, які знадобляться для вирішення того чи іншого завдання. Наприклад, одна з технік називається Poker Planning, де кожен учасник анонімно дає свою оцінку необхідних трудовитрат з конкретного завдання. Після цього команда визначає середню вагу завдання у story points або людино-годинниках та розподіляє справи за принципом «кому що подобається». При цьому щодня команда збирається на 15-хвилинний мітинг, коли кожен за пару хвилин розповідає про статуси своїх поточних завдань, у тому числі повідомляє про труднощі. Виявлену проблему команда швидко усуває, тому замовник дивиться на черговий етап роботи програміста максимально оперативно. Розробники не затягують з термінами виконання завдань через небажання зайвий раз смикати команду або марних спроб розібратися самостійно, вбиваючи дорогоцінний час. До речі, на таких міні-статусах у розробників з'являється бажання виявити себе з найкращого боку, показати, що ти відповідально підходиш до роботи. Це реально мотивує та самодисциплінує.

Все, про що було розказано в кількох попередніх розділах, більшою мірою орієнтувалося на проведення подальших досліджень з проблеми власного часу процесу та значно меншою мірою на практичні застосування. Виконуючи цю прогалину, викладемо одне із методів обчислення свого часу процесу виходячи з статистичних даних про його еволюції.

Розглянемо одновимірний процес, стан якого характеризується речовинною змінною х. Припустимо, що спостереження динамікою процесу виконуються в астрономічному часі t, отже t = t k і x = x k , k =1, ..., п - фіксовані моменти спостереження та відповідні їм значення станів процесу. Існує безліч різноманітних математичних методів, що дозволяють побудувати такі криві, які або проходять через точки (t k , Xk), або найкращим о6разом наближаються до них. Отримувані у своїй функції 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.Формує видачу результатів шляхом встановлення відповідності між значеннями т та елементами x з масиву (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 штук. Партія пропускається послідовно через 4 операції; тривалість першої операції – 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 прим. Норми часу та кількість робочих місць на операціях такі.