Повна назва Системи: Послуги з розробки пакетів програмного забезпечення (Розвиток сервісу “Громадський бюджет”). Умовне позначення: АС “Громадський бюджет” або Система.

Договір №4098 про надання послуг від 13 жовтня 2017 року. Найменування послуги: код за ДК 021:2015:72210000-0 Послуги з розробки пакетів програмного забезпечення (Розвиток сервісу “Громадський бюджет”). Шифр роботи: АС “Громадський бюджет”.

Таблиця 1. Найменування установ розробника і замовника, їх реквізити

1. Договір № 4098 про надання послуг від 13 жовтня 2017 року;
2. Календарний план надання послуг (Додаток №1 до Договору № 4098 про надання послуг від 13 жовтня 2017 року).

Підписанти:

• Замовник: Директор КП ГІОЦ – В.М. Козубський
• Виконавець: Генеральний директор ТОВ “Памак” – В.О. Пазинич

Підставою для проведення розробки Системи є такі нормативно-правові документи:

• Конституція України;
• Закон України “Про інформацію”;
• Закон України “Про електронні документи та електронний документообіг”;
• Закон України «Про адміністративні послуги»;
• Постанова Кабінету Міністрів України від 30.01.2013 р. № 57 “Про затвердження Порядку ведення Реєстру адміністративних послуг”;
• Закон України “Про звернення громадян”;
• Закон України “Про доступ до публічної інформації”;
• Закон України “Про захист інформації в інформаційно-телекомунікаційних системах”;
• Закон України “Про електронний цифровий підпис”;
• Закон України “Про захист персональних даних”;
• Постанова Кабінету Міністрів України від 04.02.1998 № 121 “Про затвердження переліку обов'язкових етапів робіт під час проектування, впровадження та експлуатації систем і засобів інформатизації”;
• Постанова Кабінету Міністрів України від 12.04.2002 № 522 “Про затвердження Порядку підключення до глобальних мереж передачі даних”;
• Постанова Кабінету Міністрів України від 10.09.2003 № 1433 “Про затвердження Порядку використання комп'ютерних програм в органах виконавчої влади”;
• Постанова Кабінету Міністрів України від 28.10.2004 № 1452 “Про затвердження Порядку застосування електронного цифрового підпису органами державної влади, органами місцевого самоврядування, підприємствами, установами та організаціями державної форми власності”;
• Постанова Кабінету Міністрів України від 29.03.2006 № 373 “Про затвердження Правил забезпечення захисту інформації в інформаційних, телекомунікаційних та інформаційно-телекомунікаційних системах”;
• ДСТУ 2394-94 “Інформація та документація. Комплектування фонду, бібліографічний опис, аналіз документів . Терміни та визначення”;
• НД ТЗІ 1.1-003-99. Термінологія в галузі захисту інформації у  комп’ютерних системах від несанкціонованого доступу;
• НД ТЗІ 1.4-001-2000. Типове положення про службу захисту інформації в автоматизованій системі;
• НД ТЗІ 2.5-004-99. Критерії оцінки захищеності інформації у комп’ютерних системах від несанкціонованого доступу;
• НД ТЗІ 2.5-005-99. Класифікація автоматизованих систем і стандартні функціональні профілі захищеності оброблюваної інформації від несанкціонованого доступу (зі Зміною №1, затвердженою наказом Адміністрації Держспецзв’язку від 15.10.2008 № 172);
• НД ТЗІ 3.6-001-2000. Технічний захист інформації. Комп’ютерні системи. Порядок створення, впровадження, супроводження та модернізації засобів технічного захисту інформації від несанкціонованого доступу;
• НД ТЗІ 3.7-001-99. Методичні вказівки щодо розробки технічного завдання на створення комплексної системи захисту інформації в автоматизованій системі;
• НД ТЗІ 3.7-003-05. Порядок проведення робіт із створення комплексної системи захисту інформації в інформаційно-телекомунікаційній системі;
• ДК 010-98 “Державний класифікатор управлінської документації”; 
• ДСТУ ISO/IEC 12207:2014 “Інженерія систем і програмного забезпечення. Процеси життєвого циклу програмного забезпечення”  
• Програма Київської міської ради від 03.03.2016 № 116/116 Про затвердження міської цільової програми “Турбота. Назустріч киянам” на 2016 - 2018 роки.
• Закон України “Про соціальні послуги”;
• ДСТУ 3396.0-96 Захист інформації. Технічний захист інформації. Основні положення;
• ДСТУ 3396.2-97 Захист інформації. Технічний захист інформації. Терміни та визначення;
• ДСТУ 2873-94 Системи оброблення інформації. Програмування. Терміни та визначення;
• ДСТУ 2941-94 Системи оброблення інформації. Розроблення систем. Терміни та визначення;
• ДСТУ ISO/IEC 2382-4:2005 Інформаційні технології. Словник термінів. Частина 4. Організація даних;
• ДСТУ ISO/IEC 2382-17:2005 Інформаційні технології. Словник термінів. Частина 17. Бази даних;
• ДСТУ ISO/IEC 2382-9:2005 Інформаційні технології. Словник термінів. Частина 9: Обмін даними;
• ДСТУ 4302:2004 Інформаційні технології. Настанови щодо документування комп`ютерних програм (ISO/IEC 6592:2000, MOD);
• ДСТУ 4145-2002 Інформаційні технології. Криптографічний захист інформації. Електронний цифровий підпис, що ґрунтується на еліптичних кривих;
• ГОСТ 19.001-77. Єдина система програмної документації. Загальні положення;
• ГОСТ 19.101-77 (СТ СЗВ 1626-79). Єдина система програмної документації. Види програм і програмних документів;
• ГОСТ 19.102-77. Єдина система програмної документації. Стадії розробки;
• ГОСТ 19.103-77. Єдина система програмної документації. Позначення програм програмних документів;
• ГОСТ 19.104-78 (СТ СЗВ 2088-80). Єдина система програмної документації. Основні написи;
• ГОСТ 19.105-78 (СТ СЗВ 2088-80). Єдина система програмної документації. Загальні вимоги до текстових програмних документів;
• ГОСТ 19.201-78 (СТ СЗВ 1627-79). Єдина система програмної документації. Технічне завдання. Вимоги до змісту та оформлення;
• ГОСТ 19.202-78 (СТ СЗВ 2090-80). Єдина система програмної документації. Специфікація. Вимоги до змісту та оформлення;
• ГОСТ 19.301-79 (СТ СЗВ 3747-82). Єдина система програмної документації. Програма та методика випробувань. Вимоги до змісту та оформлення;
• ГОСТ 19.507-79 (СТ СЗВ 2091-80). Єдина система програмної документації. Відомість експлуатаційних документів;
• ГОСТ 19.701-90 (ИСО 5807-85). Єдина система програмної документації. Схеми алгоритмів, програм, даних та систем;
• ГОСТ 19781-90 Програмне  забезпечення систем обробки інформації. Терміни  та визначення;
• ГОСТ 34.003-90. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Терміни та визначення;
• ГОСТ 34.201-89. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Види, комплектність і позначення документів при створенні автоматизованих систем;
• ГОСТ 34.601-90. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Стадії створення;
• ГОСТ 34.602-89. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання на створення автоматизованої системи;
• ГОСТ 34.603-92. Інформаційна технологія. Види випробувань автоматизованих систем;
• РД 50-34.698-90. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Автоматизовані системи. Вимоги до змісту документів;
• РД 50-682-89. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Загальні положення.

Плановий термін початку робіт по розвитку Системи та плановий термін закінчення робіт по розвитку Системи визначаються Договором №4098 про надання послуг від 13 жовтня 2017 року та Календарним планом надання послуг, що є Додатком №1 до Договору № 4098 від 13 жовтня 2017 року.

Роботи фінансуються за рахунок коштів бюджету міста Києва, які виділяються в рамках цільової програми “Електронна столиця” на 2015-2018 роки. Умови робіт закріплені у Договорі № 4098 про надання послуг від 13 жовтня 2017 року на послуги з розробки пакетів програмного забезпечення (Розвиток сервісу “Громадський бюджет”).

Порядок оформлення та приймання робіт з розвитку Системи здійснюється згідно з відповідними положеннями Договору № 4098 про надання послуг від
13 жовтня 2017 року за результатами тендеру на закупівлю послуг з розробки пакетів програмного забезпечення (Розвиток сервісу “Громадський бюджет”). Система у вигляді веб-рішення інсталюється на сервер із відповідним програмним забезпеченням. Обов’язковою умовою є використання замовником для веб-рішення Системи сертифікату безпеки ssl/tls для роботи за протоколом https. Після розгортання і налаштування проводиться тестування та навчання по роботі в адміністративній панелі Системи.

Розвиток Системи направлений на:

• Автоматизацію виборів в ГБК в Громадському бюджеті;
• Підвищення зручності реєстрації та авторизації користувачів;
• Поліпшення роботи користувачів із галереєю проектів завдяки:
  • введенню параметру “Популярні за минулу добу”, по якому можливо відбирати проекти;
  • створенню системи тематичних тегів, по яким можливо здійснювати пошук проектів по тематикам;
  • відображенню проектів зі статусом “На модерації”;
  • Підвищення ефективності контролю Модератором процесу виборів проектів (автоматичне надсилання інформації про проект відповідальним підрозділам, блокування усуненого Модератора);
  • Збільшення можливостей та зручності для авторів проектів при роботі з Системою:
    • відображати на сторінці проекту лічильник днів на збір електронних підписів;
    • інформування автора проекту про важливість заповнення контактних даних в особистому кабінеті.

Метою розвитку Системи є додання в Систему окремих модулів і функцій, спрямованих на:

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

Об’єктом автоматизації є окремі модулі процесу Громадського бюджету. Це конкурс проектів, які подають Громадяни м. Києва на частину коштів, виділену з бюджету міста Києва. В рамках поточних доробок Системи автоматизуються процеси, пов’язані з:

• Проведенням виборів в ГБК задля прозорого проведення відбору кандидатів;
• Створенням команди автору проекту та його прихильників, комунікації між ними;
• Демонстрацією реалізації проектів на різних етапах;
• Передачею даних по проекту ВСП на перегляд і експертну оцінку;
• Об’єднанням методів реєстрації Зовнішніх користувачів через інтеграцію їх в сервісі ОКК.

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

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

Регламент обслуговування обладнання, кількість і кваліфікація обслуговуючого персоналу конкретного робочого місця повинні відповідати вимогам виробника програмно-технічних засобів і бути узгодженим із Замовником. Нормальними умовами експлуатації Системи повинні бути:

• температура навколишнього повітря: +20±5 С°;
• відносна вологість повітря: 60±15 %;
• атмосферний тиск: 630-800 мм. рт. ст.

Розвиток  Системи  повинен виконуватися за принципами:

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

Система має забезпечувати наступні функції з автоматизації Громадського бюджету:

• Налаштування в Системі виборів в ГБК, враховуючи особливості параметрів Громадського бюджету;
• Реєстрацію користувачів методом ОКК задля доступу до розширеного функціоналу системи;
• Формування команди проекту задля комунікацій, доопрацювань проекту, слідкуванням за процесом голосування та реалізації;
• Редагування текстових даних на головній сторінці (редагування текстових підказок на етапах, редагування назв заголовків і підзаголовків);
• Демонстрацію реалізації проектів по етапах (система забезпечує додавання етапів і, на кожному етапі, звітів, фото-, відеоматеріалів, які ілюструють реалізацію проекту).

Для забезпечення успішного функціонування Системи повинна бути сформована структура, яка відповідає за створення та експлуатацію Системи. У складі цієї структури повинні бути працівники з ролями Персоналу:

• Модератор (мінімум 1 людина);
• Адміністратор (1 людина).

Модератор Системи  повинен:

• реалізувати правила розмежування доступу до ресурсів Системи (інформаційних, програмних, мережних, технічних);
• здійснювати та оновлювати налаштування сесії згідно чинного Положення;
• здійснювати налаштування розділів «Довідники» та «Контент» Системи та оновлювати їх;
• повідомляти технічній підтримці Системи про несправність окремих блоків.

Адміністратор в межах та згідно із заявленими в цьому Технічному завданні доопрацюваннями повинен:

• налаштувати модуль комбінованого геокодингу в довіднику “Місто” – на вкладці “Системи геокодингу”;
• включити функцію “Дозволити ГБК” в довіднику “Місто” – на вкладці “Інші налаштування”, яка дозволить створювати необмежену кількість циклів відбору кандидатів з індивідуальними налаштуваннями тривалості етапів, числа голосів та інших параметрів;
• включати мапу проектів та її відображення на картографічній основі ІАС “Майно”.

Особи, яким призначені ці ролі, повинні виконувати такі функціональні обов’язки: Таблиця 2. Функціональні обов’язки персоналу

До кваліфікації Персоналу висуваються такі вимоги:

• знання відповідної предметної сфери;
• знання основ роботи з комп’ютером та використання засобів діалогових форм;
• знання процесу Громадського бюджету та норм Положення.

Модератор має освоїти інструкцію Модератора, надану Розробником. Адміністратор має освоїти інструкцію Адміністратора, у випадку виникнення питання, що не описано в інструкції Адміністратора, звернутися до представника Розробника. Персонал, що працює з Системою і виконує функції її супроводу та обслуговування, повинен працювати у відповідності з основним робочим графіком підрозділів Замовника.

Система повинна забезпечувати такі показники призначення:

• можливість зберігання історичних даних протягом не менш ніж 20 років;
• можливість одночасної роботи до 10 000 користувачів на етапах проведення виборів в ГБК, подачі проектів та голосування за проекти;
• одночасної роботи до 2 000 користувачів на етапах розгляду проектів, визначення переможців та реалізації;
• завантаження будь-якої сторінки сайту, із відповідним інформаційним навантаженням за час – не більше 3 секунд;
• швидкість надання результатів пошуку та фільтрації із релевантними відповідями за 3-5 секунд;
• час користувальницької сесії без автоматичного виходу зі свого облікового запису – до 5 діб.

Надійність Системи повинна бути забезпечена за  наступними напрямками:

• забезпечення працездатності компонентів АПК;
• збереження даних.

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

• вимкнення живлення;
• відмови технічних засобів обробки інформації;
• помилки, збоїв або руйнування програмного забезпечення;
• тимчасової відмови ліній зв’язку. 

Надійність функціонування Системи повинна забезпечуватися:

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

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

Проектні рішення щодо створення робочих місць повинні передбачати заходи та процедури по експлуатації, які узгоджуються з вимогами “Про затвердження Правил охорони праці під час експлуатації електронно-обчислювальних машин”, затверджених наказом Державного комітету України з промислової безпеки, охорони праці та гірничого нагляду від 26 березня 2010 року № 65. Вимоги з техніки безпеки повинні бути відображені в експлуатаційних документах та забезпечувати безпеку при монтажі, налагодженні, експлуатації і ремонті технічних засобів Системи. Приміщення, у яких розміщуються технічні засоби, повинні бути обладнані протипожежною сигналізацією, дозволеною до використання в органах державної влади.

Забезпечення інформаційної безпеки Системи має задовольняти наступні умови:

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

Вимоги щодо КСЗІ визначатимуться в окремому Технічному завданні, яке буде розроблятись Виконавцем, якого буде визначено за результатами проведення окремої конкурсної процедури.

Рішення щодо ергономіки повинне забезпечувати:

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

Сайт повинен забезпечувати зручний для користувача інтерфейс, який відповідає таким вимогам:

• інтерфейс має відповідати параметрам фірмового стилю;
• повинні використовуватися шрифти:
  • шрифт заголовків та акцентів — Gotham Pro Black та Gotham Pro Bold;
  • шрифт основного тексту — Gotham Pro Regular;
  • шрифт має бути зручним для читання, різного розміру;
  • основна палітра кольорів:
    • CMYK:32% 7% 1% 0%                         RGB: #aed3ec
    • CMYK:15% 0% 0% 0%                         RGB:#d9effb
    • CMYK:51% 0% 53% 0%                       RGB:#80be87
    • CMYK:0% 0% 10% 0%                         RGB:#fffde9
    • CMYK:3% 5% 5% 0%                          RGB:#d9effb
    • CMYK:18% 20% 24% 0%                    RGB:#d9effb
    • WHITE 0% 0% 0% 0%
    • BLACK 50% 50% 50% 100%
    • додаткова палітра кольорів:
      • CMYK:2% 31% 13% 0%                       RGB:#f2bbc2
      • CMYK:2% 31% 13% 0%                       RGB:#f2bbc2
      • CMYK:40% 100% 59% 38%                RGB:#6a2a36
      • CMYK:76% 70% 59% 49%                   RGB:#353536
      • CMYK:91% 70% 52% 44%                   RGB:#23373f
      • CMYK:66% 5% 0% 0%                        RGB:#41b5e5
      • CMYK:55% 16% 11% 0%                     RGB:#74aeca
      • CMYK:55% 40% 34% 4%                     RGB:#7b868d
      • CMYK:52% 0% 86% 0%                       RGB:#80b64a
      • CMYK:70% 1% 94% 0%                       RGB:#4da341
      • CMYK:51% 0% 53% 0%                       RGB:#4da341
      • CMYK:51% 0% 53% 0%                       RGB:#4da341
      • уся текстова інформація на сайті має бути українською мовою.

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

Умови експлуатації, а також види і періодичність обслуговування технічних засобів Системи повинні відповідати вимогам експлуатації, технічного обслуговування, ремонту і зберігання, викладеним в документації їх виробників. Система повинна забезпечувати безперервний цілодобовий режим експлуатації з урахуванням часу на технічне обслуговування. Умови експлуатації, а також види і періодичність обслуговування технічних засобів Системи повинні відповідати вимогам експлуатації, технічного обслуговування, ремонту і зберігання, викладеним в документації їх виробників. Для електроживлення технічних засобів повинна бути передбачена трифазна чотирипровідна мережа з глухо заземленою нейтраллю 380/220В (+ 10-15)%, частотою 50 Гц (± 1) Гц. Кожний технічний засіб живиться однофазною напругою 220 В частотою 50 Гц через мережеві розетки з заземлюючим контактом. Технічні засоби повинні зберігати працездатність Системи при впливі наступних кліматичних факторів:

• температура навколишнього повітря від 10°С до 45°С;
• відносна вологість повітря від 40 до 80% при температурі +10°С .

Базові вимоги із забезпечення захисту інформації від несанкціонованого доступу повинні бути реалізовані організаційно-адміністративними заходами, апаратно-програмним та інженерно-технічним забезпеченням. Повинні бути реалізовані наступні механізми:

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

Повинні бути реалізовані наступні функції:

• захист трафіку на рівні автентифікації/шифрування мережевих пакетів з використанням сучасних протоколів;
• забезпечення конфіденційності та цілісності інформації шляхом здійснення її криптографічного перетворення (виконання функцій шифрування та дешифрування) та здійснення розмежування доступу до такої інформації;
• пакетної фільтрації трафіку з використанням інформації в полях заголовків мережевого і транспортного рівнів;
• закриття всіх мережевих портів, крім тих, що необхідні для функціонування Системи;
• доступ до серверів виключно через SSH та виключно за ssl-ключами;
• класифікації та маркування трафіку;
• реалізації заданого протоколу взаємодії (автентифікацію та/або захист трафіку) для кожного захищеного з'єднання, доступ в заданому захищеному режимі тільки для зареєстрованих партнерів по взаємодії;
• регульованої стійкості захисту трафіку;
• маскування топології сегмента мережі, що захищається (тунелювання трафіку);
• підтримки списку відкликаних сертифікатів (CRL – Certificate Revocation List);
• реєстрації подій.

Збереженість інформації повинна бути забезпечена у разі виникнення наступних подій (аварій, відмов тощо):

• відмова обладнання сервера;
• вимкнення живлення на робочому місці та/або на сервері баз даних;
• відмова обладнання робочої станції;
• відмова ліній зв'язку.

З метою забезпечення збереженості інформації повинно використовуватися:

• резервне копіювання;
• відновлення даних при збоях в роботі мережевого, програмного і апаратного забезпечення;
• зеркалювання рішення для забезпечення збереженості даних.

Резервне копіювання, архівація і відновлення даних повинні здійснюватися з використанням стандартних засобів СКБД і сервера застосувань, що описано нижче (див. Рисунок 42. Схема архітектури інфраструктури Системи). Контроль за функціонуванням Системи, проведення планових і позапланових регламентних робіт, усунення відмов і збоїв повинні здійснюватися спеціалізованим технічним персоналом підрозділів Замовника.

До АПК Системи ставляться такі вимоги щодо захисту від впливу зовнішніх чинників:

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

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

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

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

• у складі Системи повинні використовуватися уніфіковані технічні та програмні засоби: робочі станції, загальносистемне та мережеве програмне забезпечення, СКБД, інтерфейси, вхідні та вихідні форми документів відповідно до кожного функціонального рівня;
• програмно-технічні засоби повинні відповідати вимогам інформаційної та програмної сумісності;
• інформаційна сумісність повинна забезпечуватись використанням стандартних інтерфейсів, які регламентують правила обміну цифровою інформацією;
• програмна сумісність забезпечується шляхом застосування загальносистемного програмного забезпечення.

Система має виконувати функції, описані в розділах 4.2.1 – 4.2.12 згідно з описаними процесами. Створення нових модулів і компонентів функцій не має погіршувати стан основних функцій Системи. Всі задачі, які виконуються Системою, мають бути логічними і максимально зрозумілими для користувача, який працює в Системі. Представлені нижче макети Системи в процесі розробки можуть бути модернізовані і доповнені. Фінальні макети надаватимуться розробником у документі «Загальний опис Системи».

Загальний процес проведення Громадського бюджету зображений на схемі нижче (див. Рисунок 1. Загальна схема процесу проведення Громадського бюджету.


Рисунок 1. Загальна схема процесу проведення Громадського бюджету.
Задля підвищення зручності для користувачів і функціональності Системи передбачається створення додаткових модулів та компонентів функцій. На Рисунок 1. Загальна схема процесу проведення Громадського бюджету сірим кольором виділені підпроцеси загального процесу проведення Громадського бюджету в м. Києві, що будуть реалізовані відповідно до даного Технічного завдання, а білим кольором – блоки, які вже створені в процесі розробки Системи та функціонують. Відповідно до вимог у даному Технічному завданні у Системі будуть автоматизовані наступні етапи Громадського бюджету:

• Подання проектів;
• Розгляд проектів ВСП;
• Голосування;
• Визначення переможців;
• Планування і реалізація.

В рамках доробки Системи буде автоматизовано такі процеси:

• Проведення виборів в ГБК;
• Формування команди автора та прихильників проекту;
• Відображення реалізації проектів по стадіях.

У Системі розрізняють три основні ролі:

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

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

• Метод авторизації користувача в Системі;
• Резидентство;
• Мінімальний вік;
• Заповненість необов’язкових полів в анкеті користувача.

1. 2.        Модератор – відповідальна особа, що здійснює  налаштування у Системі всіх параметрів, що стосуються міста, налаштування сесії, зміну статусів проектів, редагування даних.

Задля надання доступу до адмінпанелі Системи, в Системі можна у будь-який момент створювати ролі Модератора, які відрізняються рівнем доступу до окремих компонентів та функцій Системи, а також змінювати їх. Кожний АРМ модератора налаштовується на множину певних функцій, виходячи із завдань і повноважень даного користувача при роботі із Системою. Роль – це сукупність прав користувача у адмінпанелі. На стартовому етапі логіка взаємодії користувачів із адміністративною панеллю Системи базується на двох ключових ролях персоналу: Модератор Системи – має дозволи на наступні дії з компонентами Системи:

• Додавання проектів, поданих в паперовому вигляді;
• Редагування проектів;
• Додавання голосів, поданих в паперовому вигляді;
• Редагування кількості голосів, у випадках, передбачених Положенням;
• Видалення голосів;
• Керування сесією;
• Керування довідниками;
• Керування контентом;
• Керування адміністраторами;
• Керування користувачами;
• Зміна статусів проектів;
• Перегляд історії змін;
• Можливість змінювати статуси проектів, у випадках, передбачених Положенням;
• Доступ до всіх проектів (поза закріпленим Модератором за проектом, ім’я якого вказано в полі “Модератор” в картці проекту);
• Перегляд статистики.

Відповідно до функціональності, що розробляється в рамках даного Технічного завдання, Модератору мають бути надані наступні права для роботи з Системою:

• Налаштовувати параметри проведення виборів в ГБК;
• Керувати розділами “Кандидати ГБК”, “Голосування ГБК”, “Сесії ГБК”;
• Підключати/відключати функцію реєстрації та ідентифікації Зовнішніх користувачів через ОКК;
• Додавати нові сторінки Сайту;
• Редагувати тексти на головній сторінці Сайту;
• Створювати текстові підказки під кожним етапом сесії на Сайті;
• Керувати розділом “Прихильники”;
• Керувати довідником “Теги”;
• Керувати довідником “Переклади”;
• Додавати в записи довідника “Відповідальні підрозділи” e-mail для відправки на них повідомлень;
• Керувати власним mail-сервером;
• Формувати та відправляти листи довільного змісту окремій групі користувачів;
• Блокувати користувача з роллю Модератора, якого було відсторонено від процесу відповідним рішенням уповноваженого органу;
• В налаштуваннях сесії визначати «Необов’язкові поля для голосування».

1. 3.         Адміністратор – відповідальна особа, яка здійснює додаткові налаштування системи, які не доступні Модератору, в межах даного Технічного завдання.

Адміністратор має всі дозволи на дії з компонентами Системи, які має Модератор, та додатково до наступних налаштувань Системи:

• розділ “Контент” – “Міста України” перед початком роботи;
• перевірити доступні типи категорій проектів в довіднику “Типи категорій”;
• за потреби включити функцію “Підвищувати права підтверджених користувачів”, яка дозволяє Зовнішнім користувачам зі статусом “Підтверджений” подавати проекти в Системі та голосувати в Системі, уникаючи перевірки на параметри “Мінімальний вік автора/голосуючого”, “Метод реєстрації”.

В межах та відповідно до заявлених доопрацювань в даному Технічному завданні Адміністратору мають бути надані наступні права для роботи з Системою:

• Налаштовувати систему комбінованого геокодингу;
• Включати функцію “Дозволити ГБК”,  яка дозволить онлайн проводити вибори в ГБК;
• Включати функцію “Дозволити ручне заповнення обов’язкових даних користувача, що не були отримані від зовнішнього джерела”;
• Включати мапу проектів та змінювати картографічну основу для відображення мапи.

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

Модуль проведення виборів в ГБК має бути розроблений таким чином:

• Розробити можливість створювати необмежену кількість циклів відбору кандидатів з індивідуальними налаштуваннями тривалості етапів, числа голосів та інших параметрів;
• Дозволити зареєстрованим в Системі представникам громадських організацій подавати заявки на конкурс в ГБК;
• Користувачам адміністративної панелі (Модераторам) додати керування заявками і відхиляти ті, що не відповідають правилам участі;
• Створити проведення голосування за представлених кандидатів в 2 тури з можливістю голосування в першому турі всіх користувачів Системи, у другому – лише учасників другого туру;
• Розробити формування рейтингу учасників за результатами голосування і відображати в Системі за певними параметрами переможців.

Якщо Положенням визначено проведення виборів в ГБК, перед початком сесії Адміністратор встановлює відмітку «Дозволити ГБК» у вкладці «Інші налаштування» в довіднику «Місто» (див. Рисунок 2  Відмітка “Дозволити ГБК” в довіднику “Місто”). Рисунок 2  Відмітка “Дозволити ГБК” в довіднику “Місто”
Процес проведення виборів в ГБК складається з наступних етапів (днем початку кожного нового етапу є наступний за днем закінчення попереднього етапу):

1. Подача заявок (див. Рисунок 3 Конкурс ГБК. Подача заявки (см. 1), Рисунок 4 Конкурс ГБК. Подача заявки (ст. 2), Рисунок 5 Конкурс ГБК. Подача заявки (ст. 3)). На рисунках зображена анкета, яку має заповнити Зовнішній користувач – кандидат на вибори в ГБК.
2. Розгляд.
3. Перший тур голосування (описано нижче, див. Рисунок 7 Процес голосування по конкурсу ГБК). На рисунку відображена схема бізнес-процесу голосування за кандидатів в ГБК. Спочатку проводиться перший тур, в якому всі Зовнішні користувачі можуть голосувати за кандидатів. В другий тур автоматично проходять кандидати, які набрали кількість голосів, що рівна параметру “Мінімальна кількість голосів для проходження в 2-й тур”.
4. Другий тур голосування (описано нижче, див. Рисунок 7 Процес голосування по конкурсу ГБК). На рисунку відображена схема бізнес-процесу голосування за кандидатів в ГБК. Після першого туру проводиться другий тур, в якому кандидати в ГБК голосують один за одного між собою.
5. Визначення переможців.

Рисунок 3 Конкурс ГБК. Подача заявки (ст. 1)
Рисунок 4 Конкурс ГБК. Подача заявки (ст. 2)
Рисунок 5 Конкурс ГБК. Подача заявки (ст. 3)
Створення і подача заявки кандидата на участь у конкурсі в ГБК відбувається згідно процесу, відображеного на Рисунок 6 Процес подання заявки на конкурс ГБК.
Рисунок 6 Процес подання заявки на конкурс ГБК
Подана заявка надходить в Систему зі статусом “На модерації”. Після цього Модератор проводить її перевірку на відповідність параметрам до ГО, вказаних в Положенні. Наприклад:

• на момент формування комісії ГО зареєстрована у місті Києві понад 1 рік;
• наявність статусу неприбутковості;
• наявність публічної фінансової звітності за минулий рік.

У випадку неможливості доопрацювати заявку, Модератор надає їй статус «Видалена», в разі дозволу доопрацювати та відредагувати – статус «Відхилена». Якщо заявка змін не потребує (первинно або після доопрацювання), вона отримує статус «Учасник 1-го туру» і публікується на Сайті. Процес проведення голосування на виборах до ГБК відображений на Рисунок 7 Процес голосування по конкурсу ГБК. Даний процес складається з першого та другого турів. Після проведення двох турів визначається повний склад Громадської бюджетної комісії, що буде діяти з дня її офіційного затвердження до обрання нової комісії на наступних виборах до ГБК. Частота проведення виборів та їх параметри визначаються Положенням.


Рисунок 7 Процес голосування по конкурсу ГБК
Опис процесу проведення онлайн-виборів в ГБК та основні учасники даного процесу описані в Таблиця 3. Основні етапи онлайн-проведення конкурсу в ГБК. Таблиця 3. Основні етапи онлайн-проведення конкурсу в ГБК

На Рисунок 8 Налаштування ГБК в адмінпанелі зображений розділ «Налаштування ГБК» в адмінпанелі. Поля, позначені зірочкою, є обов’язковими для заповнення. Даний розділ заповнює Модератор перед початком виборів в ГБК згідно з параметрами, зазначеними в Положенні. Після початку етапу подачі заявок налаштування даного блоку стають недоступними для редагування і модератор вже не може вносити в них зміни.
Рисунок 8 Налаштування ГБК в адмінпанелі
Загальний макет відображення проведення ГБК на Сайті Системи наведено на Рисунок 9 Вибори ГБК. Загальний макет:

• оформлений текст-пояснення до процесу виборів в ГБК і їх значення;
• блок логотипів партнерів;
• timeline етапів виборів в ГБК;
  • всі заявки кандидатів в ГБК, розміщені у випадковому порядку і при кожному оновленні сторінки їх порядок змінюється. В заявці відображаються текстові дані та клікабельні назви розділів, у яких можна завантажити документи, які підкріпив кандидат. Праворуч зображена кнопка “Голосувати”.

Рисунок 9 Вибори ГБК. Загальний макет
Для налаштування параметрів проведення онлайн-виборів до ГБК, Модератор встановлює параметри в Системі, які вказані в Таблиця 4. Поля для налаштування онлайн-виборів в ГБК: Таблиця 4. Поля для налаштування онлайн-виборів в ГБК

Для забезпеченняи процесу відбору заявок в Системі будуть розроблені статуси заявок в ГБК, подані в Таблиця 5. Статуси заявок користувачів для участі в виборах ГБК. Таблиця 5. Статуси заявок користувачів для участі в виборах ГБК

Заявка кандидата в ГБК складається з полів, вказаних в Таблиця 6. Поля заявки кандидата в ГБК. Примітка: Поля, позначені у Таблиця 6. Поля заявки кандидата в ГБК зірочкою, обов’язкові для заповнення.
Таблиця 6. Поля заявки кандидата в ГБК

Нотифікації (листи), які Система надсилає користувачам на різних етапах проходження їх заявки, вказані в Таблиця 7. Нотифікації ГБК. Всі нотифікації доступні в розділі “Контент” – “Шаблони листів”. Модератор може редагувати їх тему та зміст. Випадки, коли лист надсилається кандидату, вказані в Системі і не підлягають змінам. Таблиця 7. Нотифікації ГБК

Мета створення модулю інтеграції з ОКК:

• Додати можливість в рамках сесії використовувати функцію реєстрації та ідентифікації користувачів через ОКК;
• Здійснювати передачу даних користувачів, необхідних для реєстрації в рамках Системи, з ОКК;
• Здійснювати перевірку даних користувачів ОКК на відповідність зі списком користувачів, які вже були зареєстровані в Системі раніше;
• Здійснювати передачу даних про голосування від Системи до OKK.

Рисунок 10  Схема взаємодії Системи з ОКК Для реєстрації/авторизації в Системі через ОКК, Зовнішній користувач натискає «Вхід» на головній сторінці Сайту, далі натискає кнопку “Kyiv ID” в pop-up з методами реєстрації/авторизації. Після цього Система здійснює перенаправлення Зовнішнього користувача в ОКК. Виконавець не несе відповідальності за роботоздатність даного переходу. На сторінці сервісу ОКК Зовнішній користувач проходить  реєстрацію/авторизацію згідно з процедурою організації-реєстратора та потрапляє на Сайт як авторизований користувач. На Рисунок 11 Вхід через ОКК в формі реєстрації/авторизації. Крок 1 Рисунок 11зображена реєстраційна форма Зовнішніх користувачів на Сайті. Форма викликається натисканням на «Вхід» у верхньому правому кутку на будь-якій сторінці Сайту. Зліва відображений блок входу за логіном і паролем  (для вже зареєстрованих користувачів), справа – блок реєстрації з доступними методами реєстрації в поточній сесії. Логіном Зовнішнього користувача в Системі є серія та номер паспорту або номер телефону, вказаний при реєстрації. Рисунок 11 Вхід через ОКК в формі реєстрації/авторизації. Крок 1
На Рисунок 12 Вхід через ОКК в формі реєстрації/авторизації. Крок 2 зображена сторінка сервісу ОКК, яка відображається користувачу у випадку, коли він обрав реєстрацію/авторизацію через ОКК та в формі реєстрації натиснув кнопку «Вхід через KyivID». Вид і зміст даної форми може бути змінено за рішенням розробника ОКК.
Рисунок 12 Вхід через ОКК в формі реєстрації/авторизації. Крок 2
На Рисунок 13 Повідомлення про нестачу даних обов’язкових полів в обліковому записі Зовнішнього користувача показано повідомлення, яке отримує Зовнішній користувач при реєстрації в Системі, якщо Організація-реєстратор не передала дані хоча б в одне обов’язкове поле для реєстрації, які визначені в параметрах сесії в розділі «Поточна сесія». При цьому, в повідомленні вказуються назви полів, по яким не було отримано даних, задля інформування користувача про те, які дані йому буде необхідно уточнити в анкеті в Організації-реєстраторі.
Рисунок 13 Повідомлення про нестачу даних обов’язкових полів в обліковому записі Зовнішнього користувача Опис процесу взаємодії Системи з сервісом ОКК поданий в Таблиця 8. Опис процесу взаємодії з ОКК. Таблиця 8. Опис процесу взаємодії з ОКК

Таблиця 9. Набір даних користувачів, що передаються з ОКК

Таблиця 10. Структура запису про операцію надання послуги

Мета створення модулю: відобразити основні стадії реалізації проекту-переможця і проходження ним в часі цих стадій для більш якісного контролю реалізації з боку громадськості. Попередньо Модератор заповнює довідник етапів, встановлює кожному проекту послідовність необхідних етапів і має можливість після закінчення кожного етапу викласти звіт про його виконання і відзначити етап, як пройдений. На сторінці проекту зі статусом “На реалізації” заявляється блок “Реалізація”  в історії проекту для демонстрації його етапів. На Рисунок 14 Блок «Реалізація по етапам» в адмінпанелі зображена вкладка “Реалізація по етапам” в картці проекту в  адмінпанелі, яка доступна в АРМі Адміністратора та Модератора. При завершенні певного етапу реалізації проекту, Модератор в даній вкладці:

• Обирає даний етап реалізації;
• Завантажує файли, що підтверджують реалізацію (звіти, фото тощо);
• За потреби, додає коментар в необов’язкове поле «Коментар»;
• Ставить відмітку “Реалізовано” по даному етапу.

Рисунок 14 Блок «Реалізація по етапам» в адмінпанелі На Рисунок 15 Блок «Реалізація по етапам» на сторінці проекту справа в блоці «Історія проекту» відображено реалізацію проекту по етапах. Відображається:

• назва етапу; 
• коментар Модератора; 
• клікабельні назви файлів, за якими можна їх завантажити.

Рисунок 15 Блок «Реалізація по етапам» на сторінці проекту Весь опис процесів відображення проектів на реалізації по стадіях описаний в Таблиця 11. Процес відображення проектів на реалізації по стадіях.
Таблиця 11. Процес відображення проектів на реалізації по стадіях

\\ На Сайті у картці кожного проекту, що отримав статус “На реалізації”, на вкладці “Реалізація” (Див. Рисунок 14 Блок «Реалізація по етапам» в адмінпанелі) Модератор додає етапи реалізації по проекту, вибираючи їх з довідника і зберігає за допомогою кнопки "Зберегти". \\ 

\\ Користувач заходить на Сайт, обирає в меню “Переглянути проекти” будь-який з проектів зі статусом “На реалізації” і в розділі “Історія” (права частина екрану), в блоці “Етап “На реалізації” може побачити як минулі етапи реалізації, так і майбутні, а також файли звітів і коментарі до тих етапів, які вже завершилися в разі, якщо Модератор їх додав раніше.\\ 

\\  (Див. Рисунок 15 Блок «Реалізація по етапам» на сторінці проекту).\\ 

В довіднику “Етапи реалізації” Модератор додає нові статуси реалізації проектів по стадіях. Модератор може додавати й інші етапи реалізації в разі необхідності. За замовчуванням в Систему додані статуси, які позначають відповідні етапи реалізації проекту, представлені в Таблиця 12. Етапи реалізації проектів.  

Таблиця 12. Етапи реалізації проектів

У Модулі комбінованого геокодингу розробляється таке:

• Додається можливість підключати такі сервіси геокодингу як Open Street Map Nominatim (openstreetmap.org), Visicom (visicom.ua), Google Maps (maps.google.com);
• Передбачаються варіанти підключення різних режимів  (паралельний або послідовний) пошуку адрес і введення можливості задання пріоритетів при використанні декількох систем;
• В АРМ Адміністратора додається доступ до вкладки “Системи геокодингу” довідника “Місто”;
• Передбачається можливість інтеграції з ІАС «Майно» та можливість підключення карти ІАС “Майно” в основу “Мапи проектів”.

Система геокодингу здійснює пошук за адресами баз даних провайдерів сервісу геокодингу (таких як Open Street Map Nominatim, Visicom, Google Maps) та конвертує їх в координати для подальшого відображення на мапі. Система комбінованого геокодингу здійснює одночасний або послідовний пошук (в залежності від налаштувань) по базах даних провайдерів сервісу геокодингу та знаходить найбільш оптимальне значення координат. Таким чином гарантується відповідність знайденої адреси до фактичного розташування об’єкта за певною адресою. Опис панелі налаштувань комбінованого геокодингу поданий в Таблиця 13. Опис функцій панелі налаштувань сервісів геокодингу. Система має розпізнавати будь-які адреси, які вводяться Користувачем та Модератором/Адміністратором: адреса проживання користувача, адреса реєстрації користувача, адреса проекту. Усі налаштування комбінованого геокодигу в Системі здійснює Адміністратор. Модератору дані налаштування в його АРМі не доступні. Для налаштування Адміністратором геокодингу в його АРМ створюється вкладка “Сервіси геокодування” в довіднику “Міста” (Див. Рисунок 16 Вкладка «Сервіси геокодування» в довіднику «Місто») Вкладка має наступні параметри для налаштування:

1. Режим пошуку (послідовний, паралельний).
2. Підключення кожної з систем геокодингу:

• Встановлення/зняття відмітки біля назви системи геокодингу;
• Додавання API-ключа в разі потреби;
• Визначення пріоритету в пошуку.

На Рисунок 16 Вкладка «Сервіси геокодування» в довіднику «Місто» зображена вкладка «Сервіси геокодування», яка доступна в АРМі Адміністратора. В ній Адміністратор здійснює налаштування параметрів комбінованого геокодингу згідно з описом в Таблиця 13. Опис функцій панелі налаштувань сервісів геокодингу. Має бути доданий опис режимів пошуку біля назв режимів у вкладці «Системи геокодингу» в довіднику «Місто»:

• Паралельний (буде опитувати всі ввімкнені сервіси одночасно, брати дані з найбільш пріоритетного та доповнювати даними з інших джерел згідно пріоритету).

При включенні режиму «Паралельний» буде здійснюватися пошук адреси по всім системам геокодингу, по яким проставлена відмітка. При цьому спочатку буде здійснюватися пошук з системи геокодингу з пріоритетом “3” (найвищим пріоритетом), потім відповідно з пріоритетом “2” та пріоритетом “1”. Всі знайдені варіанти запису адреси з усіх трьох систем будуть відображатися у випадаючому списку в полі, куди здійснюється введення адреси. 

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

При включенні режиму “Послідовний” буде здійснюватися пошук адреси спочатку з системи геокодингу з найвищим пріоритетом “3”. В разі виявлення хоча б одного результату запису адреси він з’явиться у випадаючому списку в полі, куди здійснюється введення адреси і пошук на цьому буде зупинено. Якщо адресу не було знайдено в системі геокодингу з найбільшим пріоритетом “3”, відбувається пошук адреси в системі геокодингу з пріоритетом “2”. Якщо не знайдено в ній – здійснюється перехід до пошуку адреси в системі геокодингу з найменшим пріоритетом “1”:

• якщо пошук адреси в ній успішний – вона з’являється у випадаючому списку поля, куди здійснюється введення адреси,
• якщо пошук – не успішний, у випадаючому полі відображається текст “Немає результатів”.

Рисунок 16 Вкладка «Сервіси геокодування» в довіднику «Місто»             В Системі розроблений відкритий програмний інтерфейс, за допомогою якого ІАС “Майно” отримує від Системи дані для відображення по проектам, такі, як назва проекту, категорія проекту, його бюджет, поточний статус у Системі, автор проекту. На Рисунок 17 Поле «Адреса растрових тайтлів» у вкладці «Інші налаштування» довіднику «Місто» зображено макет створеного поля «Адреса растрових тайтлів для leaflet для інтеграції з ІАС «Майно» для відображення мапи проектів на картографічній основі ІАС «Майно». Дані можуть змінюватися залежно від налаштувань. Поле доступно в АРМі Адміністратора в довіднику «Місто» у вкладці «Інші налаштування».
Рисунок 17 Поле «Адреса растрових тайтлів» у вкладці «Інші налаштування» довіднику «Місто» Опис панелі налаштувань геокодингу для підключення комбінованого геокодингу наведено в Таблиця 13. Опис функцій панелі налаштувань сервісів геокодингу.
Таблиця 13. Опис функцій панелі налаштувань сервісів геокодингу

В процесі розробки модулю створюються наступні складові:

• відображення в верхньому і нижньому (footer)  меню розділів зі списку;
• перейменування розділів меню в рамках заданого обмеження за кількістю символів;
• додавання нових сторінок через меню адміністративної панелі з виведенням їх в розділ “Допомога”;
• додавання нових сторінок з використанням створеного шаблону “Відображення відео” із завантаженням на них відео-контенту в розділі “Допомога”;
• редагування Модератором текстів на головній сторінці Сайту;
• створення текстових підказок під кожним етапом процесу з можливістю їх зміни Модератором;
• додавання логотипу міста  в верхню частину головної сторінки з можливістю його заміни в адміністративній панелі.

На Рисунок 18 Перейменування розділів меню та зміна назв заголовків і підзаголовків за допомогою довідника «Переклади» відображено розділ “Довідники” – “Переклади”. В Системі створюється менеджер зміни назв задля заміни назви розділів і підрозділів на Сайті. 

Рисунок 18 Перейменування розділів меню та зміна назв заголовків і підзаголовків за допомогою довідника «Переклади» На Рисунок 19 Додавання текстової сторінки в розділі «Контент» - «Статичні сторінки» зображено можливість  додавання різних статичних сторінок в розділі «Контент» - «Статичні сторінки». Доробки розділу дають можливість створювати сторінки, які будуть відображатися на Сайті як окремі підрозділи розділу «Про проект». Наразі в Системі можна створювати лише дві статичні текстові сторінки:

• Правила участі
• Додаткова інформація

Рисунок 19 Додавання текстової сторінки в розділі «Контент» - «Статичні сторінки»
На Рисунок 20 Відображення текстових підказок до етапів на сайті наведено приклад, як буде відображатися підказка до етапу, яка буде відображатися при наведенні курсором на етап на timeline на Сайті. Всі підказки доступні для редагування Модератором в його АРМі протягом всієї сесії та до її початку. Рисунок 20 Відображення текстових підказок до етапів на сайті
На Рисунок 21 Поле «Логотип» у довіднику «Місто» зображено, як здійснюється додавання логотипу у поле «Логотип» в довіднику «Місто» в АРМі Модератора. Модератор завантажує в нього один файл формату .jpeg або .png. розміром до 10 МБ. До початку та під час всієї сесії Модератор може змінювати зображення. Завантажений логотип буде відображатися у верхній частині головної сторінки на Сайті. 
Рисунок 21 Поле «Логотип» у довіднику «Місто» Опис складових модуля управління статичними елементами поданий в Таблиця 14. Складові модуля управління статичними елементами.
Таблиця 14. Складові модуля управління статичними елементами

                                                                                                                                                         Всі підказки для timeline редагуються модератором до та під час сесії в розділі «переклади». Підказки мають пояснювати зміст процесів Громадського бюджету на кожному етапі. За замовчуванням в Систему додані підказки для етапів на timeline, представлені в   Таблиця 15. Підказки етапів на Timeline, додані в Систему по замовчуванню. Таблиця 15. Підказки етапів на Timeline, додані в Систему по замовчуванню

Мета створення модуля:

• будь-якому зареєстрованому користувачу подати заявку Автору проекту на включення в команду проекту з текстовим коментарем;
• Автору проекту прийняти або відхилити заявку з необов’язковим коментарем, які обґрунтовують відмову в разі відхилення;
• відправляти автоматичні повідомлення Автору проекту на e-mail про заявки прихильників і прихильникам про рішення Автора проекту;
• відображати контактні дані (телефон, e-mail) Автора проекту і його прихильників один одному;
• відображати кількість всіх прихильників проекту в картці проекту з можливістю виклику їх повного списку із зазначенням ПІБ, фото, посилання на Facebook-профіль (якщо такий є);
• в галереї проектів вибрати проекти, що мають кількість прихильників в певному діапазоні (фільтр по числу прихильників) і відключити фільтр;
• виключити прихильника зі списку Автором проекту.

Автором проекту є Зовнішній користувач, що подав проект у Системі і відповідає таким вимогам:

• “Мінімальний вік автора”;
• “Методи реєстрації авторів”;
• Щодо подання проекту нерезидентами;
• Заповнив всі поля в анкеті Зовнішнього користувача;
• Подав проект в Систему;
• Проект автора має статус відмінний від “Видалений”.

Для реалізації можливості формування команди проекту на сторінці проекту додається вкладка “Прихильники” (Див. Рисунок 24 Демонстрація прихильників (макет) проекту на сторінці проекту), на якій:

1. Автору проекту буде відображатися:

• ПІБ автора заявки прихильника;
• Фото прихильника;
• Дата отримання заявки від прихильника;
• Коментар прихильника до заявки;
• Посилання на Facebook-профіль;
• Телефон прихильника;
• E-mail прихильника;
• Статус заявки з можливістю змінити з випадаючого списку (прийняти рішення по заявці) (див. Рисунок 23 Демонстрація розділу (макет) «Прихильники» для автора проекту).

1. Всім іншим Зовнішнім користувачам відображаються наступні дані про прихильників проекту (тільки тих, чиї заявки вже погоджені Автором проекту):

• ПІБ прихильника;
• Фото прихильника;
• Посилання на Facebook-профіль прихильника проекту.

Процес додавання Автором проекту прихильника до своєї команди зображений на Рисунок 22 Процес додавання прихильника:


Рисунок 22 Процес додавання прихильника
Долучення прихильників до команди проекту можливе після проходження проектом етапу модерації. Додавання і видалення прихильників можливо на всіх наступних етапах проекту після модерації. Опис етапів процесу формування команди автора проекту та його прихильників поданий в Таблиця 16. Етапи формування команди автора проекту та його прихильників.
Таблиця 16. Етапи формування команди автора проекту та його прихильників

На Рисунок 23 Демонстрація розділу (макет) «Прихильники» для автора проекту зображено, яким чином відображається модуль «Прихильник проекту» на сторінці проекту для авторизованого автора даного проекту. Автору доступні контактні дані прихильника та стовпчик з набором статусів для надання / зняття доступів прихильників до команди проекту.   Рисунок 23 Демонстрація розділу (макет) «Прихильники» для автора проекту
На Рисунок 24 Демонстрація прихильників (макет) проекту на сторінці проекту зображено вигляд блоку «Прихильники проекту» для всіх інших Зовнішніх користувачів.
Рисунок 24 Демонстрація прихильників (макет) проекту на сторінці проекту
На Рисунок 25 Поле «Коментар» при подачі заявки прихильника зображено pop-up, який відкривається при натисканні “Стати прихильником” на сторінці проекту. Задля початку комунікації з автором прихильник може додати коментар до своєї заявки на приєднання до команди автора проекту. В pop-up додано текст, що попереджає прихильника про те, що в разі прийняття його до команди, його дані (ПІБ, фото та Facebook-профіль) будуть відображатися на сторінці проекту.   
Рисунок 25 Поле «Коментар» при подачі заявки прихильника На Рисунок 26 Pop-up після подання заявки прихильника зображено pop-up вікно, що з’являється в інтерфейсі для Зовнішнього користувача після того, як він подав заявку на приєднання до команди проекту. В pop-up повідомляється, що автор проекту розгляне заявку і прийме рішення про додання користувача до власної команди.  
Рисунок 26 Pop-up після подання заявки прихильника По отриманій заявці від прихильника на приєднання до команди проекту, у випадку, якщо автор проекту не бажає додавати даного користувача (прихильника) до команди проекту, він може поставити заявці статус «Відхилено» і написати коментар про причину відхилення заявки прихильника. Такий pop-up зображено на Рисунок 27 Поле «Коментар» при відмові автора проекту.  
Рисунок 27 Поле «Коментар» при відмові автора проекту
Процес, що описує видалення прихильника автором проекту, зображений на Рисунок 28 Процес видалення прихильника автором проекту. Видалення прихильника відбувається шляхом встановлення йому відповідного статусу «Відмовлено» в записі обраного прихильника на сторінці проекту в блоці «Прихильники». Також, за потреби, автор проекту може додати коментар про причину видалення прихильника з команди проекту, який буде зазначений у листі прихильнику (див. Пункт 5 Таблиця 16. Етапи формування команди автора проекту та його прихильників).

Рисунок 28 Процес видалення прихильника автором проекту Після отримання відмови від автора проекту, прихильник може безліч разів подавати заявку на долучення до команди даного проекту. Проте у випадку, якщо у Зовнішнього користувача була подана заявка на долучення до команди проекту і по ній встановлено статус «Прихильник, тоді даний користувач по поточному проекту не може повторно подати заявку в прихильники. Заявки на долучення прихильника проекту до команди проекту можуть приймати різні статуси в Системі в залежності від проходження такої заявки по процесам додавання та видалення прихильників проектів. Статуси заявок прихильників в Системі представлені в Таблиця 17. Статуси заявок прихильників. Таблиця 17. Статуси заявок прихильників

Мета створення функцій для поліпшення роботи користувача з галереєю проектів:

• Виводити розміри бюджетів з поділом груп розрядів;
• Ввести параметр “Популярні за минулу добу”, який буде розраховуватися Системою та дозволить збільшити залучення користувачів до голосування за проекти Громадського бюджету;
• Ввести систему тематичних тегів для проектів, де довідник тегів повинен формуватися і редагуватися Модератором Системи. Автор проекту при подачі проекту може вибрати до 5 тегів. У галереї проектів додається  фільтр всіх проектів за обраними тегами;
• Відображати проекти статусу “На модерації” без вмісту текстових полів в галереї проектів і картці, не видаляючи їх при цьому з Системи.

Для реалізації зазначених функцій були розроблені макети, подані нижче. На Рисунок 29 Роздільник груп розрядів зображено приклад представлення чисел з розподілом на групи розрядів (тисячні), де роздільником виступає пробіл. Рисунок 29 Роздільник груп розрядів
На Рисунок 30 Кнопка «Показати популярні» в галереї проектів зображений параметр «Популярні за минулу добу», який додається в Систему задля інформування Зовнішніх користувачів про те, які проекти є найбільш популярними за останню добу. Параметр позначається через зображення «зірки» на проектах, що були визначені Системою як найбільш популярні за минулу добу. За даним параметром позначку «зірка» отримують 10% проектів, які за минулу добу отримали найбільший приріст голосів. В галереї проектів розробляється фільтр проектів за параметром «Популярні». При виборі даного фільтру відображаються проекти, що визначені Системою як найбільш популярні за минулу добу.
  Рисунок 30 Кнопка «Показати популярні» в галереї проектів
Для того, щоб скинути фільтрацію за параметром «Популярні», Зовнішній користувач натискає «Показати всі проекти», що зображено на Рисунок 31 Кнопка «Показати всі проекти» в галереї проектів. Рисунок 31 Кнопка «Показати всі проекти» в галереї проектів Також, задля зручності пошуку проектів за окремими об’єктами / сферами / напрямками діяльності тощо в Системі додається можливість пошуку проектів за тегами (див. Рисунок 32. Теги проектів (макет)). Зовнішній користувач може відфільтрувати проекти в галереї проектів за окремими тегами. Можна обрати один, кілька або ж всі теги відразу.  
Рисунок 32. Теги проектів (макет) В рамках існуючої функціональності в Системі не передбачено відображення на Сайті проектів, що мають статус «На модерації» чи «Уточнюється автором». При переході за посиланням на проект з одним із таких статусів користувачам відображається повідомлення «Дана сторінка не існує». В результаті у користувачів виникало питання, чому проект видалений із Системи. Тому задля інформування користувачів, що проект знаходиться на модерації, розробляється логіка відображення проекту зі скороченим вмістом, відповідно до Рисунок 33 Сторінка проекту зі статусом «На модерації».

Рисунок 33 Сторінка проекту зі статусом «На модерації» Опис складових компоненту функцій для поліпшення роботи користувача з галереєю проектів представлений в Таблиця 18. Функції для поліпшення роботи користувача з галереєю проектів.
Таблиця 18. Функції для поліпшення роботи користувача з галереєю проектів

Мета розробки компоненту функції для Модераторів щодо поліпшення контролю за процесом виборів проектів:

• Додавати в довідник відповідальних підрозділів електронні адреси для відправки на них повідомлень. При зміні у проекту статусу на “На розгляді” відповідному підрозділу, за яким закріплено проект, повинно формуватися та приходитиме автоматичне повідомлення на E-mail про те, що необхідно провести оцінку наступного проекту з посиланням на картку проекту в системі, а також буде вказуватися критичний термін у відповідності з термінами етапів процесу;
• В адміністративній панелі налаштувати власний mail сервер;
• Додати в адміністративній панелі до блоку з E-mail повідомленнями можливість Модератору  формувати та відправляти лист довільного змісту (текстове, без використання змінних Системи) групі користувачів з певного списку:
• автори проектів поточного конкурсу;
• автори всіх років;
• підписанти за проекти поточного конкурсу;
• підписанти всіх років;
• користувачі, які голосували за проекти поточного конкурсу;
• користувачі, які голосували за проекти всіх років;
• всі користувачі. 
• Блокувати Модератора, усуненого від процесу.
• Додавати в блок “Статистика” адміністративної панелі статистику по реєстрації з різних типів пристроїв.
• Відображати кількість проектів поточного конкурсу за категоріями при виборі конкретного району у вкладці фільтрів адміністративної панелі.

Для реалізації відправки повідомлень на пошту ВСП в Системі реалізується додання відповідного поля «E-mail» для введення email, на який надсилатимутися дані по проекту в запис відповідального підрозділу згідно з Рисунок 34 Поле «Email» у записі відповідального підрозділу. Рисунок 34 Поле «Email» у записі відповідального підрозділу
На Рисунок 35 Вкладка «Налаштування пошти» в довіднику «Місто» зображено макет функції, що додає можливість створювати власний mail-сервер з наступними параметрами:

• Поштова адреса відправника;
• Ім’я відправника;
• Host;
• Порт;
• Логін;
• Пароль;
• Засіб шифрування.

Рисунок 35 Вкладка «Налаштування пошти» в довіднику «Місто» В Системі надається можливість Модератору редагувати тему та зміст листів, що надсилається користувачам у відповідних випадках у Системі. В процесі доробок буде надано можливість Модератору відправляти листи довільного змісту на будь-яких етапах сесії відповідним групам користувачів. На Рисунок 36 Кнопка «Додати користувацький лист» в розділі «Шаблони листів» показано інтерфейс з кнопкою “Додати користувацький лист”, за допомогою якої Модератор може відкрити корму створення такого листа. Рисунок 36 Кнопка «Додати користувацький лист» в розділі «Шаблони листів»
В разі, якщо одного з Модераторів усунено від участі в процесі Громадського бюджету, то Модератор, якому Адміністратором надано дозвіл «Керувати адміністраторами», може заблокувати доступ усуненому Модератору, поставивши в його обліковому записі відмітку «Заблокований», як це зображено на Рисунок 37 Відмітка «Заблокований» в записі Модератора.
Рисунок 37 Відмітка «Заблокований» в записі Модератора Опис функцій Системи для модераторів щодо поліпшення контролю за процесом виборів проектів, що будуть розроблені, представлений в Таблиця 19. Функції для модераторів щодо поліпшення контролю за процесом виборів проектів.
Таблиця 19. Функції для модераторів щодо поліпшення контролю за процесом виборів проектів

Мета створення компоненту функції для підвищення зручності реєстрації і авторизації користувачів:

• Збільшити час користувальницької сесії до 5 діб без автоматичного виходу зі свого облікового запису.
• Змінити форму реєстрації, пов’язану з каналами реєстрації ОКК, BankID так, щоб поля паролю були необов’язковими, а сама форма не відображалася користувачу в разі, якщо від постачальника даних передані всі дані для заповнення обов’язкових полів.

За замовчуванням обов’язковими полями для реєстрації Зовнішніх користувачів є:

• Прізвище;
• Імя;
• Серія та номер паспорту;
• Місто реєстрації чи Місто проживання (хоча б одне з 2х полів);
• Ідентифікаційний номер.

Опис складових компоненту функцій для поліпшення роботи користувача з галереєю проектів: 1. Збільшення часу користувальницької сесії. Збільшується час користувальницької сесії для авторизованих Зовнішніх користувачів до 5 діб. У випадках, якщо Зовнішній користувач закриває Сайт, виключає пристрій і автоматично потрапляє в свій кабінет користувача без додаткової авторизації. По закінченню 5 діб від дати та часу входу Зовнішнього користувача в Систему здійснюється автоматичний вихід авторизованого Зовнішнього користувача з його облікового запису. Якщо протягом 5 діб після авторизації Зовнішній користувач заходить в кабінет користувача – вхід виконується. По закінченню 5 діб Зовнішній користувач не може ввійти в кабінет без повторної авторизації. 2. Зміни в реєстраційній формі Якщо Організація-реєстратор передає в Систему мінімальні обов’язкові дані користувача (Прізвище, Ім’я, Ідентифікаційний номер, Серія та номер паспорту, Місто адреси проживання/Місто адреси прописки) користувачу не відображається реєстраційна форма і здійснюється його реєстрація (авторизація) в Системі. Приклад даних:

• “inn”: “0000111111”,
• “lastName”: “Коваленко”,
• “addresses”: [{“city”: “Київ”, “type”: “factual}, {“city”: “Київ”, “type”: “juridical”},
• “firstName”: “Олеся”,
• “documents”: [{“type”: “passport”, “number”: “000000”, “series”: “КС”}].

Якщо дані хоча б одного з обов’язкових полів не передаються, користувач отримує повідомлення  про це із вказанням полів з проханням дозаповнити ці дані в організації-реєстраторі: «Акаунт не містить необхідних даних: <назва поля>. Доповніть необхідні дані у організації, що передала ваші дані». Якщо Зовнішньому користувачу дозволено вручну заповнювати дані, які не передала організація-реєстратор, то Адміністратор може встановити відмітку біля функції «Дозволити ручне заповнення обов'язкових даних користувача, що не були отримані від зовнішнього джерела» в довіднику «Міста» у вкладці «Інші налаштування» адмінпанелі (див. Рисунок 38 Функція «Ручне до заповнення даних, що не були отримані з зовнішнього джерела»). Рисунок 38 Функція «Ручне до заповнення даних, що не були отримані з зовнішнього джерела» При включенні функції, якщо по поточному Зовнішньому користувачу не передано дані хоча б  одного з обов’язкових полів, в його інтерфейсі з’являється форма реєстрації. В формі відображені передані поля і червоним кольором виділені обов’язкові поля, які не передані від Організації-реєстратора. Для завершення реєстрації Зовнішньому користувачу необхідно заповнити поля, що підсвічені червоним кольором, та підтвердити збереження натисканням  кнопки «Зареєструватися» на формі реєстрації. В розділі адмінпанелі «Сесії»-«Поточна сесія» створюється розділ «Необов’язкові поля для голосування». У даному розділі Модератор  встановлює відмітки біля назв полів, без отримання яких від Організації-реєстратора Система реєструє користувача (див. Рисунок 39 Блок в сесії «Поля, необов’язкові для голосування»): Рисунок 39 Блок в сесії «Поля, необов’язкові для голосування»
Перелік полів розділу «Необов’язкові поля для голосування»:

• E-mail;
• Телефон;
• Адреса реєстрації;
• Номер квартири реєстрації;
• Адреса проживання;
• Номер квартири проживання;
• Дата народження;
• Стать.

Мета створення компоненту функції:

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

Рисунок 40 Лічильник підписів на сторінці проекту Опис складових компоненту функцій для збільшення можливостей та покращення зручності авторам проектів при роботі із системою представлений в Таблиця 20. Функції для збільшення можливостей та покращення зручності авторам проектів при роботі з Системою.
Таблиця 20. Функції для збільшення можливостей та покращення зручності авторам проектів при роботі з Системою

Мета створення компоненту функції:

• Провести перевірку коректності відображення і функціонування всіх елементів Системи  на мобільних пристроях з подальшими коригуваннями.
• Додати можливість авторам подавати проекти за допомогою планшета з розміром екраном мінімум 1024 пікселів (точок) по ширині, діагоналлю від 6 дюймів та встановленими операційними системами iOS9+, Android 5.1+.

Опис складових компоненту функцій для поліпшення роботи користувача з галереєю проектів поданий в Таблиця 21. Функції для поліпшення роботи користувача з галереєю проектів.
Таблиця 21. Функції для поліпшення роботи користувача з галереєю проектів

Мета проведення аудиту:

• Аналіз Системи щодо оптимізації під індексацію у пошукових системах;
• Надання переліку рекомендацій щодо покращення роботи з контентом Системи, покращення розмітки, принципів роботи з зовнішніми та внутрішніми посиланнями тощо.

Опис складових компонентів проведення SEO-аудиту представлений в Таблиця 22. Складові проведення SEO-аудиту Системи для поліпшення індексації у пошукових системах.
Таблиця 22. Складові проведення SEO-аудиту Системи для поліпшення індексації у пошукових системах

Інформаційне забезпечення повинно відповідати таким вимогам та можливостям:

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

Компонент класифікації і кодування повинен підтримувати процес накопичення і зберігання інформації, а також вирішення функціональних задач з мінімальними витратами пам’яті і максимальною швидкістю. Проектні рішення по системі класифікації і кодування системи повинні передбачати:

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

Математичне забезпечення повинно включати алгоритми:

• перевірки персональних даних особи;
• формування та контролю допоміжних внутрішньо-системних кодів та ключів;
• формування та контролю цілісності інформації на всіх рівнях Системи.

Лінгвістичне забезпечення Системи повинно включати розвинуті мовні засоби розробки  програмного забезпечення. Програмне забезпечення серверної частини Системи  має бути доопрацьовано на PHP 7.1 і вище за стандартами PSR-2, PSR-3, PSR-4 з використанням фреймворку Laravel 5.4 (https://laravel.com/docs/5.4/). Програмне забезпечення клієнтської частини має бути доопрацьовано на JavaScript стандарту EcmaScript 2017 з використанням пакетного менеджеру YARN. Робота з Системою проводиться за допомогою візуального інтерфейсу, який працює через веб-браузер. Всі текстові дані на Сайті та в адміністративній панелі викладені українською мовою.

Програмне забезпечення Системи  повинне складатися із:

• загальносистемного програмного забезпечення;
• прикладного програмного забезпечення.

Програмне забезпечення Системи повинно забезпечувати:

• підтримку функціонування в різнорідному апаратному і програмному середовищах;
• захист від помилок і підтримку цілісності даних;
• мінімальні витрати на закупівлю та експлуатацію.

До Загальносистемного  програмного забезпечення відносяться:

• Операційні системи (Ubuntu);
• Система забезпечення версійності та інтеграції проекту Jenkins або аналоги;
• Система моніторингу Zabbix.

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

• 4 ядра, 4 Gb RAM, 30 Gb HDD – 6 шт.;
• 2 ядра, 2 Gb RAM, 30 Gb HDD – 2 шт.;
• 2 ядра, 1 Gb RAM, 30 Gb HDD – 4 шт.;
• 8 ядра, 4 Gb RAM, 30 Gb HDD – 1 шт.;
• 2 ядра, 1 Gb RAM, 200 Gb HDD – 1 шт.

Конфігурація: 1 балансувальник, 6 додатків, 1 обробник черг, 2 mysql-server (основна та резервна база даних), 1 redis-server (redis-server: кеш сесій), 1 elasticsearch, 1 об'єктне файлове сховище, 1 сервер геокодингу. Для розміщення Системи у період, коли кількість користувачів, що одночасно знаходяться на Сайті, від  2000 до 10 000, необхідна наступна конфігурація серверів:

• 8 ядер, 4 Gb RAM, 60 Gb HDD –  1шт. (балансувальник);
• 4 ядра, 4 Gb RAM, 30 Gb HDD –  24шт. (додатки);
• 8 ядер, 24 Gb RAM, 60 Gb HDD –  1шт. (redis-server: кеш сесій);
• 4 ядра, 8 Gb RAM 1000 Gb HDD –  1шт. (об'єктне файлове сховище);
• 4 ядра, 2 Gb RAM, 30 Gb HDD –  1шт. (обробник черг);
• 32 ядра, 16 Gb RAM, 60 Gb HDD –  1 шт. (основна база даних);
• 4 ядра, 8 Gb RAM, 60 Gb HDD –  1шт. (резервна база даних);
• 4 ядра, 4 Gb RAM, 60 Gb HDD –  1шт. (elasticsearch);
• 4 ядра, 4 Gb RAM, 30 Gb HDD –  1шт. (сервер геокодингу);

На всіх серверах повинні бути ОС Ubuntu 16.04×64 LTS, root з доступом по паролю (тимчасово, в процесі автоматичної інсталяції доступ до ssh по паролю буде закритий). При збільшенні навантаження на різні компоненти, споживання системних ресурсів може зростати нелінійно, і тоді необхідна принципово інша схеми розміщення. Розробка даної схеми виходить за межі даного Технічного завдання. Система має бути налаштована під такі веб-браузери: Google Chome, IE11+, Edge, Firefox 42+, Chrome 47+, Safari 9+, Opera 35+. На прикладному рівні Системи використовуватимуться HTML5, CSS3, Js. Для розробки адміністративної панелі Системи використовуються системи php7 (OpenSSL PHP Extension, PDO PHP Extension, Mbstring PHP Extension, Tokenizer PHP Extension), MariaDB, Redis, BeanstalkD, NodeJS та фреймворк – Laravel 5.2 javascript стандарту ES6, який транслюється в ES5 за допомогою babel. Верстка адаптивна та оптимізована під усі сучасні розширення екранів моніторів, включаючи Full HD (1920*1080), екрани планшетів від 6 дюймів та смартфонів від 3,5 дюймів.

Загальна архітектурна схема рішення представлена на Рисунок 41. Загальна архітектурна схема рішення. Рисунок 41. Загальна архітектурна схема рішення Підключення зовнішніх клієнтів до служб відбувається через балансувальник навантаження на базі nginx / openresty (в разі критичних навантажень їх може бути кілька, які розподіляються через round-robin dns). Кожен балансувальник розподіляє запити між N серверами додатків, кожен з яких взаємодіє із зображеними сервісами по ізольованій внутрішній мережі (крім зовнішніх сервісів, виділених на схемі, взаємодія з якими відбувається по зовнішній мережі). Фонові завдання обробляються окремим сервісом (Додаток та Сервіс черг), який недоступний ззовні. СКБД і файлове сховище в реальному часі синхронізується з відповідними сервісами в резервному оточенні (дзеркало) за допомогою master-slave реплікації. Детальна схема архітектури інфраструктури Системи представлена на Рисунок 42. Схема архітектури інфраструктури Системи:  
Рисунок 42. Схема архітектури інфраструктури Системи Резервний MySQL сервер  є slave-реплікою основого. Усі конфігурації ПЗ серверів, а також процеси розгортання системи, контролюються за допомогою Ansible. Тестове середовище доступне за окремим посиланням і є стиснутою до одного сервера копією продуктового середовища

Вимоги до метрологічного забезпечення не передбачаються.

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

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

Загальний склад робіт по розвитку Системи складається з реалізації наступних модулів:

• проведення виборів в Громадську Бюджетну Комісію (далі – ГБК), що надаватиме можливість забезпечення громадського контролю за ходом попереднього відбору проектів;
• інтеграції з Особистим Кабінетом Киянина (https://id.kyivcity.gov.ua/, https:%%//%%my.kyivcity.gov.ua) (далі – ОКК), який призначено для створення додаткового каналу доступу до Системи з метою якісного розширення аудиторії користувачів;
• відображення проектів на реалізації по стадіях;
• комбінованого геокодингу;
• управління статичними елементами;
• формування команди автора проекту та його прихильників.

Також для підвищення зручності  користувачів при роботі з Системою створюються такі компоненти функцій:

• для поліпшення роботи користувача з галереєю проектів:
• введення відображення груп розрядів в числових значеннях;
• розробка параметру “Популярні за минулу добу”;
• створення системи тематичних тегів для ефективного пошуку проектів;
• розробка методики відображення проекту зі статусом “На модерації” на Сайті;
• для модераторів щодо поліпшення контролю за процесом виборів проектів:
  • створення можливості автоматичного надсилання даних по проекту закріпленим ВСП;
  • додання власного mail-серверу;
  • розробка функції надсилання кас томних листів різним групам користувачів;
  • блокування модератора, усуненого від процесу;
  • для підвищення зручності реєстрації і авторизації користувачів:
    • збільшення користувацької сесії до 5 діб;
    • створення конструктору налаштування обов’язковості полів для Зовнішніх користувачів, що бажають підписати/проголосувати за проект;
    • для збільшення можливостей та покращення зручності авторам проектів при роботі із системою:
    • відображення кількості днів, що залишилась на збір електронних підписів;
    • зображення даних по кількості електронних підписів, необхідних кожному проекту на його сторінці.

Додатково проводиться  повноцінне  користувацьке тестування і SEO (Search Engine Optimization) – аудит Системи.

Порядок контролю та приймання Системи повинен відповідати етапам, наведеним  у таблиці: Таблиця 23. Етапи контролю та приймання Системи

У ході надання послуг по даному Технічному завданню на об’єкті автоматизації необхідно виконати послуги по підготовці та введенню розробленого програмного забезпечення в дію. Замовник повинен забезпечити виконання такого:

• визначити відповідальних осіб за проведення приймальних випробувань програмного забезпечення Системи;
• разом з Виконавцем провести попередні випробування розробленого програмного забезпечення.

Склад і зміст документів, що розроблюються, визначаються згідно з ДСТУ 3973-2000, ДСТУ 3974-2000, ГОСТ 34.201-89, РД 50-34.698-90,  ДСТУ 3008-95 і складає:

• Технічне завдання;
• Керівництво Зовнішнього користувача;
• Керівництво Модератора;
• Керівництво Адміністратора;
• Загальна інструкція по розгортанню та налагодженню рішення;
• Інструкція з формування та ведення бази даних;
• Загальний опис Системи;
• Програма та методика попередніх випробувань;
• Протокол попередніх випробувань;
• Програма та методика випробувань;
• Протокол випробувань;
• Акт приймання системи в дослідну експлуатацію.

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

1. Договір № 4098 про надання послуг від 13 жовтня 2017 року з додатками.
2. Закон України “Про інформацію”;
3. Закон України “Про захист персональних даних”;
4. Закон України “Про захист інформації в інформаційно-телекомунікаційних системах”;
5. Закон України “Про доступ до публічної інформації”;
6. Постанова Кабінету Міністрів України від 04.02.1998 № 121 “Про затвердження переліку обов’язкових етапів робіт під час проектування, впровадження та експлуатації засобів інформатизації”;
7. Наказ Уповноваженого Верховної Ради України з прав людини від 08.01.2014 № 1/02-14 “Про затвердження документів у сфері захисту персональних даних”;
8. ГОСТ 34.601-90. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Стадії створення;
9. ГОСТ 34.602-89. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання на створення автоматизованої системи;

Рисунок 1. Загальна схема процесу проведення Громадського бюджету. 28 Рисунок 2  Відмітка “Дозволити ГБК” в довіднику “Місто”. 32 Рисунок 3 Конкурс ГБК. Подача заявки (ст. 1). 33 Рисунок 4 Конкурс ГБК. Подача заявки (ст. 2). 33 Рисунок 5 Конкурс ГБК. Подача заявки (ст. 3). 34 Рисунок 6 Процес подання заявки на конкурс ГБК.. 34 Рисунок 7 Процес голосування по конкурсу ГБК.. 36 Рисунок 8 Налаштування ГБК в адмінпанелі 40 Рисунок 9 Вибори ГБК. Загальний макет. 41 Рисунок 10  Схема взаємодії Системи з ОКК.. 50 Рисунок 11 Вхід через ОКК в формі реєстрації/авторизації. Крок 1. 51 Рисунок 12 Вхід через ОКК в формі реєстрації/авторизації. Крок 2. 52 Рисунок 13 Повідомлення про нестачу даних обов’язкових полів в обліковому записі Зовнішнього користувача. 52 Рисунок 14 Блок «Реалізація по етапам» в адмінпанелі 59 Рисунок 15 Блок «Реалізація по етапам» на сторінці проекту. 60 Рисунок 16 Вкладка «Сервіси геокодування» в довіднику «Місто». 64 Рисунок 17 Поле «Адреса растрових тайтлів» у вкладці «Інші налаштування» довіднику «Місто». 65 Рисунок 18 Перейменування розділів меню та зміна назв заголовків і підзаголовків за допомогою довідника «Переклади». 68 Рисунок 19 Додавання текстової сторінки в розділі «Контент» - «Статичні сторінки». 68 Рисунок 20 Відображення текстових підказок до етапів на сайті 69 Рисунок 21 Поле «Логотип» у довіднику «Місто». 69 Рисунок 22 Процес додавання прихильника. 76 Рисунок 23 Демонстрація розділу (макет) «Прихильники» для автора проекту. 80 Рисунок 24 Демонстрація прихильників (макет) проекту на сторінці проекту. 81 Рисунок 25 Поле «Коментар» при подачі заявки прихильника. 82 Рисунок 26 Pop-up після подання заявки прихильника. 82 Рисунок 27 Поле «Коментар» при відмові автора проекту. 83 Рисунок 28 Процес видалення прихильника автором проекту. 83 Рисунок 29 Роздільник груп розрядів. 84 Рисунок 30 Кнопка «Показати популярні» в галереї проектів. 85 Рисунок 31 Кнопка «Показати всі проекти» в галереї проектів. 86 Рисунок 32. Теги проектів (макет). 87 Рисунок 33 Сторінка проекту зі статусом «На модерації». 87 Рисунок 34 Поле «Email» у записі відповідального підрозділу. 91 Рисунок 35 Вкладка «Налаштування пошти» в довіднику «Місто». 92 Рисунок 36 Кнопка «Додати користувацький лист» в розділі «Шаблони листів». 92 Рисунок 37 Відмітка «Заблокований» в записі Модератора. 93 Рисунок 38 Функція «Ручне до заповнення даних, що не були отримані з зовнішнього джерела»  98 Рисунок 39 Блок в сесії «Поля, необов’язкові для голосування». 99 Рисунок 40 Лічильник підписів на сторінці проекту. 100 Рисунок 41. Загальна архітектурна схема рішення. 108 Рисунок 42. Схема архітектури інфраструктури Системи. 109

Таблиця 1. Найменування установ розробника і замовника, їх реквізити. 11 Таблиця 2. Функціональні обов’язки персоналу. 20 Таблиця 3. Основні етапи онлайн-проведення конкурсу в ГБК.. 37 Таблиця 4. Поля для налаштування онлайн-виборів в ГБК.. 41 Таблиця 5. Статуси заявок користувачів для участі в виборах ГБК.. 42 Таблиця 6. Поля заявки кандидата в ГБК.. 43 Таблиця 7. Нотифікації ГБК.. 44 Таблиця 8. Опис процесу взаємодії з ОКК.. 53 Таблиця 9. Набір даних користувачів, що передаються з ОКК.. 57 Таблиця 10. Структура запису про операцію надання послуги. 58 Таблиця 11. Процес відображення проектів на реалізації по стадіях. 60 Таблиця 12. Етапи реалізації проектів. 62 Таблиця 13. Опис функцій панелі налаштувань сервісів геокодингу. 65 Таблиця 14. Складові модуля управління статичними елементами. 69 Таблиця 15. Підказки етапів на Timeline, додані в Систему по замовчуванню.. 74 Таблиця 16. Етапи формування команди автора проекту та його прихильників. 77 Таблиця 17. Статуси заявок прихильників. 84 Таблиця 18. Функції для поліпшення роботи користувача з галереєю проектів. 88 Таблиця 19. Функції для модераторів щодо поліпшення контролю за процесом виборів проектів  93 Таблиця 20. Функції для збільшення можливостей та покращення зручності авторам проектів при роботі з Системою.. 100 Таблиця 21. Функції для поліпшення роботи користувача з галереєю проектів. 101 Таблиця 22. Складові проведення SEO-аудиту Системи для поліпшення індексації у пошукових системах. 103 Таблиця 23. Етапи контролю та приймання Системи. 112


 

Зауваження: Нижче наведений текст Угоди користувача (Згоди на обробку персональних даних) може бути в подальшому змінений за ініціативою Замовника. Зміст “Згоди на обробку персональних даних. Угода Користувача”: Реєструючись, Ви підтверджуєте свою згоду на обробку персональних даних, а також підтверджуєте, що ознайомились та погоджуєтесь на збір та обробку персональних даних та приймаєте Угоду користувача. Згода на збір та обробку персональних даних: Реєструючись на даному веб-порталі, Я:

• надаю згоду на обробку своїх персональних даних, зазначених мною у електронній анкеті під час реєстрації на веб-порталі;
• приймаю Угоду користувача;
• підтверджую те, що ознайомлений(-а) з текстом Повідомлення суб’єкту персональних даних та правами, наданими мені згідно ст. 8 Закону України “Про захист персональних даних”.

Повідомлення суб’єкту персональних даних: На виконання вимог Закону України “Про захист персональних даних”, Ваші персональні дані, у складі та змісті зазначених в електронній анкеті під час реєстрації на сайті, включені до бази персональних даних, володільцем якої є комунальне підприємство “Головний інформаційно-обчислювальний центр” (далі – КП ГІОЦ). Метою участі КП ГІОЦ є  надання можливості залучення користувачів до участі у бюджетному процесі та електронному голосуванні за різні проекти, що впроваджуватимуться у місті Києві у встановленому порядку. Надані Вами персональні дані можуть передаватися органам місцевого самоврядування і державним органам у відповідних, адекватних та ненадмірних межах, необхідних для виконання мети з якою здійснюється обробка персональних даних. Відповідно до ст. 8 Закону України “Про захист персональних даних” суб'єкт персональних даних має право: 1) знати про джерела збирання, місцезнаходження своїх персональних даних, мету їх обробки, місцезнаходження або місце проживання (перебування) володільця чи розпорядника персональних даних або дати відповідне доручення щодо отримання цієї інформації уповноваженим ним особам, крім випадків, встановлених законом; 2) отримувати інформацію про умови надання доступу до персональних даних, зокрема інформацію про третіх осіб, яким передаються його персональні дані; 3) на доступ до своїх персональних даних; 4) отримувати не пізніш як за тридцять календарних днів з дня надходження запиту, крім випадків, передбачених законом, відповідь про те, чи обробляються його персональні дані, а також отримувати зміст таких персональних даних; 5) пред'являти вмотивовану вимогу володільцю персональних даних із запереченням проти обробки своїх персональних даних; 6) пред'являти вмотивовану вимогу щодо зміни або знищення своїх персональних даних будь-яким володільцем та розпорядником персональних даних, якщо ці дані обробляються незаконно чи є недостовірними; 7) на захист своїх персональних даних від незаконної обробки та випадкової втрати, знищення, пошкодження у зв'язку з умисним приховуванням, ненаданням чи несвоєчасним їх наданням, а також на захист від надання відомостей, що є недостовірними чи ганьблять честь, гідність та ділову репутацію фізичної особи; 8) звертатися із скаргами на обробку своїх персональних даних до Уповноваженого* або до суду; 9) застосовувати засоби правового захисту в разі порушення законодавства про захист персональних даних; 10) вносити застереження стосовно обмеження права на обробку своїх персональних даних під час надання згоди; 11) відкликати згоду на обробку персональних даних; 12) знати механізм автоматичної обробки персональних даних; 13) на захист від автоматизованого рішення, яке має для нього правові наслідки. * Відповідно до ст. 4 Закону України “Про захист персональних даних” Уповноважений – це Уповноважений Верховної Ради України з прав людини (Омбудсмен).
Угода користувача: Ця Угода Користувача (далі – “Угода”) укладається між Користувачем та комунальним підприємством “Головний інформаційно-обчислювальний центр” і регулює використання сайту: https://gb.kyivcity.gov.ua/ (далі – “Сайт”), адміністрування якого здійснюється КП ГІОЦ. 1. Загальна частина 1. При використанні будь-якої частини Сайту, Користувач автоматично погоджується з умовами даної Угоди та іншими правилами, що передбачені на Сайті. 2. Умови Угоди поширюються на всіх користувачів Сайту – як на незареєстрованних користувачів, так і на зареєстрованих, що мають будь-який обліковий запис. Під обліковим записом розуміється сукупність інформації про користувача та даних авторизації/автентифікації (логін, пароль тощо). 2. Права, обов'язки та відповідальність Користувача і КП ГІОЦ 1. Повний доступ до Сайту, зокрема ознайомлення з більш повною інформацією про інших користувачів, відправлення повідомлень, можливі тільки для зареєстрованого Користувача (що створив обліковий запис). 2. Якщо Користувач вважає, що на Сайті є наявна інформація, яка порушує його права, Користувач зобов'язаний повідомити про це КП ГІОЦ та надати йому інформацію, яка підтверджує дане порушення прав. У випадку якщо Користувач надасть неправдиву інформацію про порушення його прав, він несе повну відповідальність за заподіяну шкоду. 3. Користувачеві заборонено: - сприяти розпалюванню релігійної, расової або міжнаціональної ворожнечі; - вчиняти дії, що порушують права і свободу, честь і гідність будь-якої особи; - ображати будь-кого; - використовувати нецензурні вислови, навіть якщо вони маскуються іншими символами; - зловживати розміщенням не інформативних даних; - провокувати словесну війну, що не має відношення до первинної причини суперечки; - створювати декілька облікових записів та користуватися ними одночасно на Сайті, якщо фактично вони належать одній і тій самій особі; - вчиняти дії, спрямовані на введення інших користувачів в оману; - надавати в користування свій обліковий запис та/або логін і пароль від свого облікового запису третім особам; - реєструвати обліковий запис від імені або замість іншої особи. При цьому, дозволена реєстрація від імені та за дорученням іншої фізичної особи або юридичної особи за умови  одержання необхідних повноважень у порядку й формі, передбачених законодавством України; - розміщувати інформацію (включаючи будь-які матеріали), що порушує авторські права, права на знаки для товарів, робіт і послуг, права промислової власності та/або права на інші  об'єкти інтелектуальної власності, що належать КП ГІОЦ та/або третім особам; - розміщувати інформацію, що порушує права й законні інтереси третіх осіб (у тому числі, розміщення фотографій і відеороликів, основним об'єктом яких є людина, якщо ця людина  не давала згоди на розміщення на Сайті фотографії або відео з її участю); - розміщувати матеріали рекламного, еротичного, порнографічного або образливого характеру; - використовувати будь-які комп'ютерні програми для автоматизованого збору інформації на Сайті; - здійснювати незаконний збір, систематизацію, зберігання або поширення персональної інформації інших користувачів; - намагатися одержати доступ до облікового запису та/або логіну й паролю іншого Користувача будь-яким способом, включаючи, але не обмежуючись, шляхом обману,  зловживання довірою, підбору логіна й пароля; - розміщувати комп'ютерні віруси або програми, здатні перервати або порушити нормальну функціональність комп'ютерного обладнання та програмного забезпечення, а також  засобів телекомунікації будь-яких осіб. 4. Відповідальність Користувача: - Користувач самостійно відповідає за будь-яке використання інформації, що розміщена на Сайті. - Користувач самостійно несе відповідальність перед третіми особами за свої дії або бездіяльність при використанні Сайту. - Користувач зобов'язується самостійно та за свій рахунок врегулювати всі претензії третіх осіб, що пов'язані з дією або бездіяльністю Користувача при використанні Сайту. - Якщо Користувач не доведе зворотнє, будь-які дії, здійснені з використанням його облікового запису та/або його логіна й пароля, вважаються здійсненими цим Користувачем. - У випадку розміщення Користувачем на Сайті інформації або здійснення інших дій, що не відповідають умовам Угоди, КП ГІОЦ має право без повідомлення, виключно на власний розсуд, видалити розміщену Користувачем інформацію, включаючи ту інформацію, у відношенні якої важко визначити її відповідність Угоді та/або законодавству, що застосовується. - За порушення умов даної Угоди Користувачем, КП ГІОЦ має право без попереднього повідомлення блокувати доступ Користувача до Сайту та/або видалити обліковий запис Користувача. 5. Відповідальність КП ГІОЦ: - КП ГІОЦ не несе відповідальності за використання третіми особами інформації, розміщеної Користувачем на Сайті, включаючи її копіювання, відтворення й поширення, здійснені як у рамках Сайту, так і іншими можливими способами. - КП ГІОЦ не відшкодовує збиток, прямий або непрямий, заподіяний Користувачеві або третім особам у результаті використання або невикористання, у т.ч. неможливості використання Сайту. - КП ГІОЦ не приймає на себе зобов'язань по перевірці, зміні та контролю інформації, що розташована будь-ким на Сайті, не гарантує і не несе відповідальності за достовірність інформації, її законність, якість та відповідність конкретним запитам і потребам користувачів Сайту. - КП ГІОЦ не несе відповідальності за зміст сайтів, що не належать йому, посилання на які можуть бути присутні на Сайті, і не гарантує їхньої доступності, коректної роботи й відповідності заявленій тематиці. 3. Конфіденційність 1. У випадку, якщо при використанні Сайту Користувачеві будь-яким способом стала відома інформація відносно КП ГІОЦ та/або третіх осіб, яка відповідно до законодавства України відноситься до конфіденційної та/або до Комерційної таємниці, Користувачу заборонено зберігати, використовувати й поширювати таку інформацію. 2. Користувач розуміє й погоджується з тим, що розміщуючи на Сайті інформацію, у відношенні до якої Користувачем самостійно не передбачено обмеження доступу, будь-яка третя особа може одержати доступ до цієї інформації. 4. Інші умови

1. КП ГІОЦ має право вносити зміни в дану Угоду. Усі внесені до Угоди зміни будуть доступні у вигляді нової редакції Угоди. Усі зміни Угоди набувають чинності з моменту їх публікації на Сайті. Використовуючи послуги Сайту Користувач підтверджує згоду з новими умовами Угоди в редакції, що діє на момент використання Користувачем Сайту.
2. КП ГІОЦ не несе відповідальності за шкоду або збитки, яких зазнав Користувач або треті особи в результаті помилкового розуміння або нерозуміння умов даної Угоди, інструкцій або вказівок про порядок використання Сайту, щодо порядку розміщення даних та інших технічних питань.
3. Користувач надає КП ГІОЦ право надсилати йому повідомлення, що містять інформацію про Сайт, послуги або інформацію рекламно-тематичного характеру.
4. У випадку визнання недійсної або нездійсненної будь-якої частини даної Угоди, інші частини Угоди залишаються чинними. Відмова кожної зі сторін від будь-якого положення або умов даної Угоди, або будь-яке їх порушення не скасовує дію цієї Угоди або її умов.
5. Сайт надається КП ГІОЦ “як є”. КП ГІОЦ не гарантує відповідність Сайту цілям і очікуванням Користувача, його постійну безперебійну і безпомилкову роботу.
6. КП ГІОЦ має право на технічне та технологічне оновлення сайту та на проведення відповідних технічних робіт для його підтримки та розвитку.
7. КП ГІОЦ може в будь-який момент і без повідомлення Користувача поступитися своїми правами за даною Угодою третій стороні.
8. До даної Угоди та відносинам між КП ГІОЦ і Користувачем, що виникають у зв’язку з використанням Сайту, застосовується законодавство України. Кожна сторона незаперечно погоджується з тим, що відповідні суди України мають виняткову юрисдикцію відносно будь-яких претензій, спорів або розбіжностей, що стосуються Угоди та використання Сайту.

  rest_documentconversion_latest_conversion_thumbnail_29041776_1