Розробка модуля Єдиної державної електронної системи управління галуззю рибного господарства еРиба: “Система дистанційного контролю” / Development of the module of the Unified State Electronic System for Fisheries Management “Remote Control System””

Показати схожі тендери

Повернутися до списку закупівель

Закупівля Розробка модуля Єдиної державної електронної системи управління галуззю рибного господарства еРиба: “Система дистанційного контролю” / Development of the module of the Unified State Electronic System for Fisheries Management “Remote Control System”” від Фонд «Євразія», проєкт міжнародної технічної допомоги «Підтримка цифрової трансформації».

Очікувана вартість:

0 USD (Без ПДВ)

Вартість подання пропозиції:

20.4 грн.

Перевірити КЕП

Тип закупівлі:

Спрощені закупівлі

Тендер:

UA-2024-12-05-006435-a

Id Tender:

ec3896fd523640e3bbe15e5a245c63af

Статус:

Кваліфікація переможця

Дата публікації оголошення:

05.12.2024 11:33

Остання зміна:

21.01.2025 08:43

Подання пропозицій ( Завершено )

з 20.12.2024 12:00 до 27.12.2024 18:00

Завершено

Період уточнень

з 05.12.2024 11:33

до 20.12.2024 12:00

Поточний період

Період кваліфікації

з 27.12.2024 18:00

Основні параметри
Лоти
Донор
Контакти
Кваліфікація

Розробка модуля Єдиної державної електронної системи управління галуззю рибного господарства еРиба: “Система дистанційного контролю” / Development of the module of the Unified State Electronic System for Fisheries Management “Remote Control System””

Звернення за тендером: Розробка модуля Єдиної державної електронної системи управління галуззю рибного господарства еРиба: “Система дистанційного контролю” / Development of the module of the Unified State Electronic System for Fisheries Management “Remote Control System””

Тема: Functional / Non-Functional

Зміст: Functional 1. Ролі користувачів системи: 1.1. > "Має права на отримання та перегляд інформації в системі відповідно *до наданих прав* у разі нормативного врегулювання." Чи могли б ви деталізувати ваше бачення способу надання прав користувачам подібних ролей? Виглядає так, що одночасно мають бути реаізована рольова модель доступу з можливістю уточнення рівня доступу до конкретних об'єктів моніторингу, карт, графіку руху і т.д. 1.2. Яка прогнозована кількість користуавчів системи? 2. Об'єкти моніторингу: 2.1.> "Об'єкт моніторингу може мати індивідуальний атрибутивний склад (авто, судно тощо)" Таким чином кожен об'єкт моніторингу буде містити набір стандартних даних (назва, опис, фото і т.д.) та набір налаштовуваних атрибутів (тип, потужність). З приводу налаштовуваних атрибутів - які типи даних планується зберігати в таких атрибутах об'єктів? Приклад: Текст. Число. Можливість вибору із списку. Логічне значення - "Так" / "Ні". Дата. Інші варіанти. 2.2. > "Встановлення терміну дії об'єкта моніторингу (з-по)" 2.2.1. Яким чином даний параметр впливає на процеси / інтерфейси в системі? 2.2.2. Які процеси мають запускатись на початку та закінчені терміну дії? 2.3. > "Можливість видалення об’єктів моніторингу." Чи правильно ми розуміємо, що при видаленні об'єкту моніторинга - всі збережені по цьому об'єкту дані мають залишитись в системі, а не видалятись разом із цим об'єктом? В подальшому має підтримуватись можливість перегляду історичних даних по всім об'єктами - активним, протермінованим та видаленим. 2.4. Для запуску системи - Чи потрібно виконувати стартовий імпорт об'єктів моніторингу із інших структурованих джерел? Якщо так - то що це за джерала і в якому вигляді там зберігаються об'єкти? 2.5. Яка прогнозована кількість об'єктів моніторингу, які мають спостерігатись системою? 3. Карти: 3.1. Які вимоги до вибору картаграфічного сервісу, який можу бути інтегрований у систему? 4. Графік руху об'єктів: 4.1. > "Проміжні точки маршруту відображаються з додатковою інформацією." Яка кількість точок маршруту за одиницю часу (хвилину, годину, добу)? 5. Геозони: 5.1. > "Індивідуальні налаштування для кожної геозони" Чи могли б ви навести приклади опису та налаштувань геозон? 6. Події: 6.1. Чи правильно ми розуміємо, що події мають створюватись користувачами із відповідними ролями (не автоматично на базі даних моніторингу)? 6.2. Яка прогнозована кількість подій в системі (у об'єкта / всьго, в одиницю часу - доба / тиждень / місяць)? 7. Правопорушення: 7.1. > "Правопорушення може бути створено як результат фіксації події." Підкажіть кількість зв'язків "Тип Події" - "Клас Правопорушення", для випадків створення Правопорушення із заповненням даними із Події? 8. Документи: 8.1. > "Можливість створення документів визначених постановою КМУ № 153 та іншими документами пов’язаними з елементами наявними в системі." Поділіться список документів, для яких потрібно буде створити шаблони в системі? Які типи об'єктів може містити документ - заголовки, абзац тексту, картинка, таблиця, список? 8.2. > "Можливість налаштування умов для автоматичної генерації документів." Поділіться вашим баченням процесу налаштування умов генерації документів? Поділіться списком можливих тригерів, які можуть ініціювати створення документу? 9. Інформаційні сповіщення: 9.1. > "Можливість налаштування умов для автоматичного генерування інформаційних сповіщень." Поділіться списком можливих тригерів, які можуть ініціювати відправку сповіщення? 9.2. > "Можливість налаштування способів доставлення інформаційних сповіщень (електронна пошта, SMS, сповіщення в системі, месенджери)." Підтримку яких месенджерів необхідно забезпечити в системі? 10. Технічні засоби системи дистанційного контролю: 10.1. > "Автоматичне приймання сигналу від ТЗСДК, що працюють на базі супутникових систем GPS (трекери на базі стільникового зв’язку, GSM) та/або INMARSAT та/або станцій наземного спостереження АІС" > "Підтримка інтеграції з різними типами трекерів (зокрема, GPS та INMARSAT трекери)." Надайте опис інтерфейсу/ів отримання сигналів від ТЗСДК? Які технічні вимоги та обмеження підключення до даного інтерфейсу/ів? 10.2. > "Перелік трекерів для інтеграції не повинен бути обмежений можливе додавання в систему інших пристроїв ТЗСДК." Тут мається на увазі, що архітектура рішення має дозволяти реалізувати додавання інших типів пристроїв із залученням розробників? 10.3. Надайте схеми описів протоколів та приклади отримуваних даних із GPS трекерів INMARSAT станцій наземного спостереження АІС 10.4. Яка прогнозована кількість об'єктів моніторингу, які мають спостерігатись системою? 11. Інші питання: 11.1. Поділіться баченням статусної моделі об'єктів в системі: Об'єкти моніторингу Правопорушення Документи 11.2. > "Глобальні налаштування" Чи могли б ви навести список очікуваних налаштувань? 11.3. > "Моделі процесів" Поділіться список процесів та сценаріями їх виконання? 11.4. > "Шаблони звітів" Які звіти та коли мають генеруватись в системі? 11.5. > "Дашборди" Які дашборди необхідно реалізувати в системі? Non-Functional 12. > 9. АДМІНІСТРАТИВНА ІНФРАСТРУКТУРА > PROD середовище забезпечується Розробником до моменту завершення терміну гарантійної підтримки. Чи могли б ви навести список акредитованих (дозволених) провайдерів хмарного доступу чи дата центрів. Наприклад: Amazon (AWS), Google (GCP), Digital Ocean, Hostpro.ua, Denovo.ua 13. > 10. ТЕХНОЛОГІЧНИЙ СТЕК > Для розробки Системи мають використовуватись мови програмування: > FRONT-END - PHP7, Laravel, Vue, Angular (на вибір). Чи допускається використання ReactJS?

Дата оприлюднення звернення: 10.12.2024 14:28

Functional 1. Ролі користувачів системи: 1.1. > "Має права на отримання та перегляд інформації в системі відповідно *до наданих прав* у разі нормативного врегулювання." Чи могли б ви деталізувати ваше бачення способу надання прав користувачам подібних ролей? Виглядає так, що одночасно мають бути реаізована рольова модель доступу з можливістю уточнення рівня доступу до конкретних об'єктів моніторингу, карт, графіку руху і т.д. Відповідь: в системі має бути реалізовано дві точки входу - публічна частина та частина для роботи співробітників системи. Відповідно до цих точок входу будуть будуть деталізовані ролі користувачів. Для внутрішніх користувачів має бути доступний фукнкіонал по відображеню всіх карт та об?єктів переміщення 1.2. Яка прогнозована кількість користуавчів системи? Відповідь: орієнтовно буде відображатись в режимі реального часу до 1.5 об?єктів, під об?єктами мається на увазі транспортні засоби на яких розміщені GPRS трекети 2. Об'єкти моніторингу: 2.1.> "Об'єкт моніторингу може мати індивідуальний атрибутивний склад (авто, судно тощо)" Таким чином кожен об'єкт моніторингу буде містити набір стандартних даних (назва, опис, фото і т.д.) та набір налаштовуваних атрибутів (тип, потужність). З приводу налаштовуваних атрибутів - які типи даних планується зберігати в таких атрибутах об'єктів? Приклад: Текст. Число. Можливість вибору із списку. Логічне значення - "Так" / "Ні". Дата. Інші варіанти. Відповідь: точні атрибути будуть деталізовані на рівні ТЗ 2.2. > "Встановлення терміну дії об'єкта моніторингу (з-по)" 2.2.1. Яким чином даний параметр впливає на процеси / інтерфейси в системі? Відповідь: на систему він не впливає - це виключно дозвільний парамтр для об?єкту 2.2.2. Які процеси мають запускатись на початку та закінчені терміну дії? Відповідь: конкретизуйте будь ласка питання… 2.3. > "Можливість видалення об’єктів моніторингу." Чи правильно ми розуміємо, що при видаленні об'єкту моніторинга - всі збережені по цьому об'єкту дані мають залишитись в системі, а не видалятись разом із цим об'єктом? В подальшому має підтримуватись можливість перегляду історичних даних по всім об'єктами - активним, протермінованим та видаленим. Відповідь: все вірно, ці данні мають зберегтись в відповідній бібліотеці 2.4. Для запуску системи - Чи потрібно виконувати стартовий імпорт об'єктів моніторингу із інших структурованих джерел? Якщо так - то що це за джерала і в якому вигляді там зберігаються об'єкти? Відповідь: так треба буде доповнювати базу існуючими об?єктами 2.5. Яка прогнозована кількість об'єктів моніторингу, які мають спостерігатись системою? Відповідь: орієнтовно до 2 тисяч об'єктів моніторингу 3. Карти: 3.1. Які вимоги до вибору картаграфічного сервісу, який можу бути інтегрований у систему? Відповідь: вимоги будуть уточнені на етапі формування ТЗ 4. Графік руху об'єктів: 4.1. > "Проміжні точки маршруту відображаються з додатковою інформацією." Яка кількість точок маршруту за одиницю часу (хвилину, годину, добу)? Відповідь: під точкою розуміємо відображення об?єкта в режимі реального часу (посекундна) 5. Геозони: 5.1. > "Індивідуальні налаштування для кожної геозони" Чи могли б ви навести приклади опису та налаштувань геозон? Відповідь: як приклад, мати можливість вибрати тип слоїв, вибору точек, чи вибір полігонних геозон, чи фільтр виведених об?єктів 6. Події: 6.1. Чи правильно ми розуміємо, що події мають створюватись користувачами із відповідними ролями (не автоматично на базі даних моніторингу)? Відповідь: так 6.2. Яка прогнозована кількість подій в системі (у об'єкта / всьго, в одиницю часу - доба / тиждень / місяць)? Відповідь: це питання буде розкрито на етапі написання ТЗ 7. Правопорушення: 7.1. > "Правопорушення може бути створено як результат фіксації події." Підкажіть кількість зв'язків "Тип Події" - "Клас Правопорушення", для випадків створення Правопорушення із заповненням даними із Події? Відповідь: кількість подій буде визначатись на етапі ТЗ, в будь-якову випадку це буде бібліотека з переліком 8. Документи: 8.1. > "Можливість створення документів визначених постановою КМУ № 153 та іншими документами пов’язаними з елементами наявними в системі." Поділіться список документів, для яких потрібно буде створити шаблони в системі? Які типи об'єктів може містити документ - заголовки, абзац тексту, картинка, таблиця, список? Відповідь: ці документи будуть надані на етапі створення ТЗ 8.2. > "Можливість налаштування умов для автоматичної генерації документів." Поділіться вашим баченням процесу налаштування умов генерації документів? Поділіться списком можливих тригерів, які можуть ініціювати створення документу? Відповідь: відповідно до типу документа буде створена бібліотека з визначеними атрибутами 9. Інформаційні сповіщення: 9.1. > "Можливість налаштування умов для автоматичного генерування інформаційних сповіщень." Поділіться списком можливих тригерів, які можуть ініціювати відправку сповіщення? Відповідь: мається на увазі створення бібліотеки з 5-10 видами сповіщень як приклад про несанкціоновану діяльність судна, чи перебування судна в забороненій зоні 9.2. > "Можливість налаштування способів доставлення інформаційних сповіщень (електронна пошта, SMS, сповіщення в системі, месенджери)." Підтримку яких месенджерів необхідно забезпечити в системі? Відповідь: в першу чергу це електронна пошта та безкоштовний який буде обраний у випадку необхідності 10. Технічні засоби системи дистанційного контролю: 10.1. > "Автоматичне приймання сигналу від ТЗСДК, що працюють на базі супутникових систем GPS (трекери на базі стільникового зв’язку, GSM) та/або INMARSAT та/або станцій наземного спостереження АІС" > "Підтримка інтеграції з різними типами трекерів (зокрема, GPS та INMARSAT трекери)." Надайте опис інтерфейсу/ів отримання сигналів від ТЗСДК? Які технічні вимоги та обмеження підключення до даного інтерфейсу/ів? Відповідь: ця відповідь буде нанада на етапі написання ТЗ 10.2. > "Перелік трекерів для інтеграції не повинен бути обмежений можливе додавання в систему інших пристроїв ТЗСДК." Тут мається на увазі, що архітектура рішення має дозволяти реалізувати додавання інших типів пристроїв із залученням розробників? Відповідь: відповідно до відслідковування об?єктів буде закуплений один вид трекерів 10.3. Надайте схеми описів протоколів та приклади отримуваних даних із GPS трекерів INMARSAT станцій наземного спостереження АІС Відповідь:, це питання буде пропрацьовуватись на етапі створення ТЗ 10.4. Яка прогнозована кількість об'єктів моніторингу, які мають спостерігатись системою? Відповідь: орієнтовно до 2 тис. об?єктів 11. Інші питання: 11.1. Поділіться баченням статусної моделі об'єктів в системі: Об'єкти моніторингу Правопорушення Документи Відповідь: статуси будуть визначені на етапі створення ТЗ 11.2. > "Глобальні налаштування" Чи могли б ви навести список очікуваних налаштувань? Відповідь: налаштування будуть узгоджуватись на етапі формування ТЗ 11.3. > "Моделі процесів" Поділіться список процесів та сценаріями їх виконання? Відповідь: потрібно конкретизувати про які саме процеси йде мова 11.4. > "Шаблони звітів" Які звіти та коли мають генеруватись в системі? Відповідь: основна ціль звітів це показати діяльність компонентів чсистеми, точна кількість буде визначена на етапі формування ТЗ 11.5. > "Дашборди" Які дашборди необхідно реалізувати в системі? Відповідь: Вітаю, перелік дашбордів буде визначений відповідно до основних блоків роботи системи Non-Functional 12. > 9. АДМІНІСТРАТИВНА ІНФРАСТРУКТУРА > PROD середовище забезпечується Розробником до моменту завершення терміну гарантійної підтримки. Чи могли б ви навести список акредитованих (дозволених) провайдерів хмарного доступу чи дата центрів. Наприклад: Amazon (AWS), Google (GCP), Digital Ocean, Hostpro.ua, Відповідь: один з акредитованих в Україні провайдерів хмарного доступу “Гігаклауд” Denovo.ua 13. > 10. ТЕХНОЛОГІЧНИЙ СТЕК > Для розробки Системи мають використовуватись мови програмування: > FRONT-END - PHP7, Laravel, Vue, Angular (на вибір). Чи допускається використання ReactJS? Відповідь: залежить від того що саме ви хочете реалізувати на ReactJS

Дата оприлюднення відповіді: 11.12.2024 09:24

Тема: Загальне звернення

Зміст: У рамках підготовки до участі в тендері хотіли б уточнити таку інформацію: Чи визначено початкову або очікувану суму тендеру? Якщо ні, то на якому етапі вона стане відомою? Чи є можливість узгодити терміни надання послуг у рамках тендеру? Будемо вдячны за надання відповіді

Дата оприлюднення звернення: 11.12.2024 13:26

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

Дата оприлюднення відповіді: 11.12.2024 16:41

Тема: Яку саме інформацію необхідно включити до документа "Портфоліо організації"?

Зміст: Яку саме інформацію необхідно включити до документа "Портфоліо організації"?

Дата оприлюднення звернення: 11.12.2024 16:52

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

Дата оприлюднення відповіді: 12.12.2024 09:39

Тема: валюта пропозиції

Зміст: Уточніть в якій валюті подавати пропозицію? Помітили, що в різних документах до тендеру зустрічаються різні валюти.

Дата оприлюднення звернення: 12.12.2024 12:38

Валюта пропозиції - долар США. Просимо подавати ваші пропозиції в доларі США. Дякуємо за питання.

Дата оприлюднення відповіді: 12.12.2024 12:52

Тема: Додаток №5

Зміст: чи можна форму додатку №5 доповнювати додатковими спеціалістами та етапами розробки, оскільки наведена форма не враховує всі необхідні етапи та необхідних спеціалістів?

Дата оприлюднення звернення: 12.12.2024 12:41

Так, Ви маєте нагоду редагувати додаткові статті витрат в Додатку 5 і видалити/додати саме ті, які ви вважаєте за доцільне. Зверніть увагу на коректність формул у формі, вони повинні правильно підсумовувати всі витрати.

Дата оприлюднення відповіді: 12.12.2024 12:54

Тема: Уточнення щодо можливості підписання NDA та формату подання бюджету

Зміст: 1. Чи розглядається можливість підписання угоди про нерозголошення (NDA) для забезпечення конфіденційності під час обміну інформацією, що стосується тендеру? 2. Чи допускається внесення даних у "Детальний бюджет" у валюті USD у зв’язку зі змінами курсу?

Дата оприлюднення звернення: 12.12.2024 13:09

1. На етапу тендеру - ні. 2. Так, вітається заповнення всіх документів в доларах США.

Дата оприлюднення відповіді: 13.12.2024 13:54

Тема: оподаткування ПДВ

Зміст: Прохання вказати (надати посилання на документ), яким документом Замовник підтверджує чинність п. 197.11 ст. 197 Податкового кодексу України - а саме, про звільнення від оподаткування - постачання товарів та послуг на митній території України та ввезення на митну територію України товарів, що фінансуються за рахунок міжнародної технічної допомоги, яка надається відповідно до міжнародних договорів України, згода на обов’язковість яких надана у встановленому законодавством порядку.

Дата оприлюднення звернення: 13.12.2024 12:31

Переможцю тендера буде надана картка акредитації та план закупівель, що підтверджують звільнення від оподаткування проєкту міжнародної технічної допомоги. https://www.kmu.gov.ua/diyalnist/mizhnarodna-dopomoga/pereliki-zareyestrovanih-proektiv-z-planami-zakupivel проект під номером 5458-03

Дата оприлюднення відповіді: 13.12.2024 13:53