0 800 330 331
Увійти /
  • Відкриті торги з особливостями
  • Однолотова
  • КЕП
  • 5

Модернізація інформаційно-комунікаційної системи «Платформа цифрових мобільних сервісів «Київ цифровий» № 1-2026

Кваліфікація

від початку періоду пройшло 9 робочих днів

17 661 666.00 UAH з ПДВ
Період уточнення: 17.02.2026 15:32 - 22.02.2026 00:00
Відповідь надана

Технічні питання

Номер: 7bb16b15c75f434eb1077c532e1788e5
Пов'язаний елемент: Закупівля
Дата опублікування: 18.02.2026 23:14
Опис: Запитання щодо модернізації ІКС «Київ Цифровий» 1. Загальні технічні та архітектурні питання Технологічний стек: Які версії Ubuntu, PHP, MySQL та Laravel використовуються в Системі на даний момент? На базі яких технологій розроблено мобільний додаток (нативно/кросплатформово)? Який стейт-менеджмент та підхід до архітектури застосовано? Документація API: Чи є можливість отримати актуальну технічну документацію (Swagger/OpenAPI) на існуючі сервіси для оцінки обсягу робіт з модернізації? Взаємодія: Який підхід використовується для взаємодії мобільного додатка з бекендом? 2. Сервіс «Твоя кров рятує» (п. 4.10.1, 4.1.2) Джерела даних та синхронізація: Чи існує готова зовнішня база даних центрів крові та їхніх потреб (API)? Якщо центри мають власні БД, чи передбачається автоматична синхронізація з ними, чи оновлення даних відбуватиметься вручну адміністраторами через адмін-панель? Профіль донора: Як передбачається заповнення даних про групу крові та статус донора: ручне введення користувачем чи інтеграція з зовнішніми системами (наприклад, «Дія» або «Helsi»)? Геотаргетинг: Чи реалізовано в Системі функціонал прив’язки користувача до конкретного району міста? Якщо так, то як визначається район (за реєстрацією, за GPS чи за вибором користувача)? Система сповіщень (Push): * Чи повинна бути реалізована фільтрація розсилок одночасно за групою крові та за районами, де є потреба в донації? Чи повинна адміністрація мати можливість відправляти пуш-сповіщення конкретній особі (таргетовано)? Чи передбачаються шаблони для сповіщень, чи кожен текст пишеться адміністратором вручну? Підтвердження донації: Як має фіксуватися факт донації — автоматично через інтеграцію з медзакладом чи за ініціативою самого донора в додатку? 3. Безкоштовне паркування для осіб з інвалідністю (п. 4.10.2) Верифікація статусу: Яким чином здійснюється підтвердження статусу особи з інвалідністю? Чи передбачена інтеграція з реєстрами Мінсоцполітики, сервісом «Дія» або іншими державними системами? Механіка для користувача: Чи повинна особа зі статусом просто позначати місце паркування в додатку без оплати, чи система має автоматично ідентифікувати пільгу при спробі оплати? Контроль: У якій системі/інтерфейсі інспектори з паркування будуть бачити підтвердження безкоштовного паркування для таких осіб? 4. Наскрізна авторизація з Порталом послуг (п. 4.10.3, 4.1.2) Доступи та токени: Для реалізації переходу без повторної авторизації, чи буде Виконавцю надано доступ до Порталу послуг або забезпечено механізм обміну токенами між додатком «Київ Цифровий» та Порталом? Про який саме Портал йде мова (веб-версія чи інша ІКС)? Реалізація: Чи передбачається синхронізація сесій між мобільним додатком та браузером на сторонньому пристрої (наприклад, через QR-авторизацію)? 5. API для ІКС МІП (п. 4.10.4) Навантаження: Яка очікувана інтенсивність запитів від Ситуаційного центру та чи є специфічні вимоги до швидкості передачі даних при реагуванні на інциденти? 6. Модернізація сервісу «Нотифікації» та Опитування (п. 4.10.6, 4.1.2) Керування дозволами: З огляду на обмеження iOS/Android, чи влаштовує Замовника варіант, коли модальне вікно лише спрямовує користувача в системні налаштування смартфона для ввімкнення сповіщень? Опитування: Чи передбачається створення окремого розділу для опитувань у додатку, чи опитування мають бути інтегровані безпосередньо в текст пуш-повідомлення (interactive notifications)? Чи може Замовник надати візуальні приклади (макети) бажаної реалізації? 7. Семантична система кольорів (п. 4.10.8) Дизайн-система: Чи надасть Замовник готову дизайн-систему (наприклад, у Figma) з уже визначеними токенами, чи розробка системи токенів та підтримки темної/світлої тем повністю покладається на Виконавця? Чи має бекенд керувати кольоровими схемами через API? 8. Автотестування (п. 4.11) Обсяг: Які саме сценарії (user flows) є пріоритетними для покриття автоматизованими тестами на етапі модернізації? Будемо вдячні за відповіді. З повагою.
Відповідь: Доброго дня, шановний Учасник! Уважно розглянувши Ваше запитання КП ГІОЦ повідомляє наступне: 1. Загальні технічні та архітектурні питання Питання: Які версії Ubuntu, PHP, MySQL та Laravel використовуються? Які технології застосовано в мобільному додатку? Відповідь: Система працює на актуальних стабільних версіях ПЗ з регулярними оновленнями безпеки. Детальна інформація щодо версій і технологічних рішень буде надана переможцю після підписання відповідних договорів та NDA. Питання: Чи можна отримати Swagger/OpenAPI документацію? Відповідь: Актуальна технічна документація API існує та буде надана переможцю процедури закупівлі. Питання: Який підхід використовується для взаємодії мобільного застосунку з бекендом? Відповідь: Взаємодія здійснюється через захищені API з використанням сучасних механізмів автентифікації та авторизації. 2. Сервіс «Твоя кров рятує» Питання: Чи є готова зовнішня база даних центрів крові та чи передбачена автоматична синхронізація? Відповідь: Передбачається можливість інтеграції з зовнішніми API за їх наявності. У разі відсутності — має бути реалізований функціонал оновлення даних через адмін-панель. Питання: Як заповнюється профіль донора? Відповідь: Базовий сценарій — ручне заповнення користувачем. Питання: Як визначається район користувача? Відповідь: Не передбачено функціонал прив’язки до району. Питання: Чи повинна бути фільтрація push-сповіщень за групою крові та районом? Відповідь: Так, має бути реалізована можливість сегментації за групою крові, по району не передбачається сегментації. Питання: Чи можлива таргетована відправка конкретній особі? Відповідь: Ні, не можлива. Питання: Чи будуть шаблони повідомлень? Відповідь: Так. Механізм шаблонів вже в нас реалізовано, тому це не предмет модернізації. Питання: Як фіксується факт донації? Відповідь: Базово — шляхом підтвердження користувачем у застосунку. 3. Безкоштовне паркування для осіб з інвалідністю Питання: Як підтверджується статус особи з інвалідністю? Відповідь: Можливість підтвердження статусу особи з інвалідністю вже реалізована в Системі. Питання: Як працює механіка для користувача? Відповідь: Пільга має застосовуватися автоматично після підтвердження статусу в системі та після початку сесії паркування. Питання: Де інспектори бачать підтвердження? Відповідь: Інформація має відображатися в АРМ Інспектора з паркування. 4. Наскрізна авторизація з Порталом послуг Питання: Як буде реалізовано SSO та обмін токенами? Відповідь: Механізм буде визначений у межах технічної реалізації з дотриманням вимог інформаційної безпеки. Доступи надаються переможцю відповідно до регламенту. Питання: Чи передбачена синхронізація сесій (наприклад, через QR)? Відповідь: Ні. 5. API для ІКС МІП Питання: Яке очікуване навантаження? Відповідь: Конкретні параметри визначатимуться на етапі технічного проєктування. 6. Нотифікації та опитування Питання: Чи прийнятний варіант перенаправлення користувача до системних налаштувань для ввімкнення push? Відповідь: механізм буде обговорюватись в технічному завданні. Питання: Чи буде окремий розділ для опитувань? Відповідь: Сервіс «Опитування» вже реалізований. 7. Семантична система кольорів Питання: Чи надається готова дизайн-система? Відповідь: Базові гайдлайни надаються. Розробка або розширення системи токенів входять до обсягу робіт. Питання: Чи має бекенд керувати кольоровими схемами через API? Відповідь: Можливість такого керування може бути передбачена за результатами технічного проєктування. 8. Автотестування Питання: Які сценарії пріоритетні для автоматизації? Відповідь: Ключові користувацькі сценарії (авторизація, платежі, сповіщення, основні сервіси). В технічних вимогах є перелік.
Дата відповіді: 20.02.2026 16:47