Змоделювати систему масового обслуговування.
Змінюючи вихідні параметри знайти результуючі параметри системи, а саме:
a.Середню затримку в черзі(кожного пристрою).
b.Середнє значення вимог, що були згенеровані під час моделювання, та ті, що пройшли систему (кожного пристрою).
c.Середнє значення за часом кількість вимог в черзі (кожного пристрою).
d.Коефіцієнт зайнятості пристроїв (кожного пристрою).
e.Середнє значення вимог.
3.Знайти оптимальну завантаженість системи та обчислити основні характеристики СМО за допомогою формул (тільки для параметрів, що задані в варіанті):
a.пропускна здатність системи,
b.середня довжина черги,
c.середня кількість заявок, що знаходилися в системі,
d.середнійчасперебування в черзі,
e.загальний час перебування заявки в системі,
f.коефіцієнт зайнятості каналів,
g.коефіцієнт простоюканалів.
4.Дослідити змодельовану систему з іншими вихідними параметрами. З’ясувати, при яких параметрах система буде зайнята не менш ніж на 95%, а при яких параметрах канали будуть простоювати.
Моделювання мережі автоматизованих робочих місць
Вихідні дані.
1. Мережа АРМ організована на базі трьох персональних ЕОМ, що виконує функції інтелектуальних терміналів. АРМ мають доступ до центрального ЕОМ через комунікаційний процесор.
2. На кожному терміналі задача формується в середньому через t c (експоненціальний розподіл), причому на виконання в центральну ЕОМ йде 25 % задач. Інші задачі виконуються в автономному режимі.
3. Час обслуговування задачі в комунікаційному процесорі і центральної ЕОМ має експонентний розподіл з математичними очікуваннями відповідно μ 1 с та μ 2 с.
4. Після виконання в центральній ЕОМ задача повертається через комунікаційний процесор на відповідний термінал, ініціюючи тим самим формування нової задачі.
Ціль. Розробити модель для аналізу процесу функціонування мережі АРМ протягом однієї години.
Параметри: t = 10, μ 1 = 1, μ 2 = 12.
Бюджет: 1000 UAH Термін: 5 днів
Доброго времени суток.
Есть опыт решения подобных задач, сделаю с комментариями.
Готов обсудить детали проекта и установить точные цену и сроки.
скажите, а как это относится к категории, где в основном визуализаторы?
мне кажется, тут надо что-то типа управления проектами или маркетинговые исследования, может проектирование.
12 січня 2021
так как категории математическое моделирование не было, я выбрала похожую по названию. спасибо за замечание, я учту😉
Шукаємо досвідченого Shopify-розробника для створення повноцінного інтернет-магазину з нуля з обов'язковою інтеграцією з Amazon. Що потрібно зробити: Інтеграція з Amazon як основа проєкту: синхронізація товарів, залишків та замовлень між Shopify та обліковим записом продавця на Amazon. Налаштування магазину будується з урахуванням цієї інтеграції з самого початку. Налаштування магазину: кастомізація теми, структура каталогу, картки товарів, кошик, оформлення замовлення — все узгоджується з логікою інтеграції з Amazon. Технічна оптимізація для AI-видимості (GEO): структуровані дані, файл llms.txt, оптимізація контенту під відповіді AI-асистентів (ChatGPT, Perplexity, AI Overviews тощо), правильна семантична розмітка сторінок. Базове SEO-налаштування: метатеги, sitemap, швидкість завантаження, мобільна адаптивність. Підключення платіжних систем. Встановлення необхідних додатків (відгуки, email-маркетинг, аналітика тощо). Тестування магазину перед запуском.
Потрібно допомогти переосмислити та побудувати чисту relational-схему для внутрішньої операційної системи на Airtable. Поточна база вже використовується командою, але вона виросла органічно: структура частково плоска, частина таблиць/в’юшок використовується активно, частина майже не використовується, а документи зараз радше “підтягують” інформацію в Airtable, хоча в ідеалі Airtable має стати джерелом правди і генерувати потрібні операційні артефакти. Потрібна не просто допомога з формами чи автоматизаціями, а саме структурна робота: аналіз поточної логіки, проєктування relational-схеми, створення чистої нової бази/інстансу, документація та рекомендації щодо міграції до нової схеми. І потенційно можливо навіть впровадження Контекст системи: Є два основні напрями: Feedback system Система для збору й обробки сигналів від зовнішніх радників, фокус-груп, внутрішніх команд та stakeholders. Має підтримувати: signal log / реєстр сигналів; advisor tracking; feedback intake; synthesis dashboard; status / gates / recommendations; close-the-loop логіку. Product catalog У каталозі продуктів зараз близько 400 записів, приблизно 100 з них активні/live. Потрібно краще структурувати продукти, статуси, зв’язки, джерела даних, lifecycle/gate logic та звітність. Поточний стан: Airtable вже існує і використовується командою. Поточна точність даних приблизно 80%. Схема переважно flat, не relational. Активно використовуються лише перші кілька таблиць/вкладок: Частина validation gates, tasks/decisions і dashboard views поки майже не використовується. Немає PII. Будь-яка робота з live base має бути максимально обережною: без змін у production без погодження. Ідеальний підхід — аналіз структури та побудова нової чистої бази окремо у Sandbox. Що потрібно зробити: Phase 1 — Audit & architecture recommendation Подивитися на поточну структуру Airtable. Визначити, які таблиці/поля/в’юшки реально потрібні, які дублюються, які можна об’єднати або прибрати. Запропонувати relational data model. Описати основні entities, relationships, primary keys, linked records, lookup/rollup logic. Запропонувати clean schema для Проєкту + Product catalog. Визначити, які dashboards/interfaces потрібні для різних користувачів. Підготувати короткий architecture memo або schema map. Phase 2 — Build clean Airtable base Створити нову чисту Airtable base / instance. Налаштувати таблиці, поля, linked records, views, basic interfaces. Налаштувати базову dashboard/reporting логіку. Підготувати migration map: як переносити дані зі старої структури в нову. Задокументувати структуру так, щоб команда могла підтримувати її після передачі. За потреби — запропонувати automation strategy, але без надмірної складності. Очікувані deliverables: Airtable schema map. Нова clean Airtable base. Таблиці + relationships + key fields. Views/interfaces для основних користувачів. Migration recommendation. Коротка документація для команди. Рекомендації щодо governance: хто вносить дані, хто апрувить зміни, які поля є обов’язковими, як уникати дублювання. Опційно: 1 короткий handoff call / Loom walkthrough. Важливі security / access правила: Без PII. Без небезпечних токенів або персональних інтеграцій. Не можна підключати AI/MCP/ChatGPT/Claude до live Airtable. Якщо потрібен доступ до існуючої бази, він має бути read-only або через експорт/скріншоти/структурний опис. Будь-які записи/зміни робляться тільки в новій тестовій/чистій базі, не в live production. Кого шукаю: Ідеальний кандидат має досвід: Airtable base architecture; relational schema design; Airtable interfaces, views, forms, automations; migration/cleanup of messy Airtable bases; product operations / CRM / workflow systems; documentation and handoff; У відгуку, будь ласка, вкажіть: Приклади Airtable-баз або систем, які ви будували. Чи був у вас досвід перетворення flat Airtable structure у relational schema. Як би ви підійшли до audit → schema design → build. Орієнтовну оцінку годин для Phase 1. Ваш hourly rate або fixed-price пропозицію для першого етапу. Чи готові працювати під NDA. Формат роботи: Почати бажано найближчим часом. Спочатку можна зробити невеликий paid discovery/audit, після чого перейти до повного build.
Потрібно перепідв'язати договір оферти в футері на новий, в компанії змінився регламент Завдання на 20 хвилин
Технічне завдання: інструмент звірки рахунків з банком, картами та бухгалтеромЗагальна мета Потрібен локальний інструмент (скрипт/невеликий додаток на Python), який запускається вручну раз на 1-2 місяці на моєму комп'ютері і робить звірку між: Рахунками, які я виставив клієнтам і отримав від постачальників (PDF-файли та фото квитанцій, що лежать у пошті Gmail) Банківською випискою (Excel) Витратами по кредитним картам (Excel, може бути кілька файлів — кілька карт) Excel-файлом від бухгалтера, в який він вносить рахунки для звітності в податкову та ПДВЩо повинен робити інструмент1. Збір рахунків з пошти (Gmail) Підключення через Gmail API (OAuth) Пошук листів за заданий період (наприклад, останні 2 місяці) з вкладеннями Завантаження вкладень: PDF-файли та зображення (фото квитанцій/чеків) Розпізнавання даних з кожного рахунка: дата, сума, назва постачальника/клієнта, номер рахунка (якщо є) Для PDF — витягування тексту безпосередньо Для зображень — розпізнавання тексту (OCR), включаючи текст на івриті2. Читання Excel-файлів Банківська виписка (доходи та витрати) Один або кілька файлів витрат по кредитним картам Excel від бухгалтера зі списком внесених рахунків (в ньому є тільки сума + дата + назва контрагента, єдиного номера рахунка для співставлення немає)3. Логіка співставлення Співставлення записів між джерелами за комбінацією: сума + дата (з допустимим відхиленням) + назва контрагента (нечітке порівняння тексту, оскільки назви можуть трохи відрізнятися).4. Перевірки, які потрібно виконати A. Виставлені рахунки на всі доходиДля кожного надходження грошей у банку — перевірити, чи є відповідний рахунок, який я виставив. Якщо немає — позначити як "доходи без виставленого рахунка". B. Збережені рахунки на всі визнані витратиДля кожного витрату в банку/на картах, який відноситься до категорії визнаних витрат — перевірити, чи є збережений рахунок. Якщо немає — позначити як "витрата без збереженого рахунка". C. Звірка зі списком бухгалтераПорівняти список рахунків, які я зібрав (з пошти), зі списком, який бухгалтер вніс і відправив у податкову/ПДВ. Позначити: Рахунки, які я зібрав, але яких немає у файлі бухгалтера (можливо, не були передані або не внесені) Записи у файлі бухгалтера, для яких не знайшовся відповідний рахунок у моїй колекції D. Перевірка зарплатного листкаПеревірити, що сума, зазначена в зарплатному листку, відповідає сумі, яка фактично списана/надійшла в банку.5. Підсумковий звіт Результат — один Excel-файл з кількома листами: Доходи без виставленого рахунка Витрати без збереженого рахунка Рахунки, відсутні у бухгалтера Записи бухгалтера без відповідного рахунка Звірка зарплатного листка з банком Несумісності/проблемні рядки повинні бути візуально виділені (кольором).Технічні деталі Мова: Python Excel: pandas + openpyxl PDF: витягування тексту (pdfplumber/PyMuPDF) OCR зображень: з підтримкою івриту (бажано використовувати Claude API з підтримкою зображень замість класичного Tesseract, для кращої точності з івритом) Gmail API: google-api-python-client, OAuth (потрібно буде створити проект у Google Cloud Console — це буде зроблено замовником/виконавцем спільно) Результат зберігається як Excel-файл локально на комп'ютері Інтерфейс: достатньо командного рядка (CLI), без необхідності у веб-інтерфейсіФормат здачі Вихідний код проекту Коротка інструкція по запуску (включаючи, як підключити свій Gmail і де покласти вхідні Excel-файли) Інструкція по створенню credentials у Google Cloud Console, якщо це не було зроблено заздалегідьДодатково Готовий надати приклади структури Excel-файлів (банк, карти, файл бухгалтера) та приклади рахунків (PDF і фото) для тестування.