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

1. Затвердити Порядок розробки та впровадження програмно-інформаційних комплексів Єдиної автоматизованої інформаційної системи Держмитслужби України.

2. Начальнику Департаменту інформаційних технологій та митної статистики Копосову С.А., начальникам митних органів виконувати роботи з розробки та впровадження програмно-інформаційних комплексів з обов'язковим дотриманням вимог цього наказу.

3. Контроль за виконанням наказу покласти на заступника Голови Служби Пашка П.В.

1.1. Дія цього Порядку розроблення та впровадження програмно-інформаційних комплексів Єдиної автоматизованої інформаційної системи Держмитслужби України (далі - Порядку) поширюється на програмно-інформаційні комплекси, включаючи їх поєднання, які створюються в рамках Єдиної автоматизованої інформаційної системи Державної митної служби України (далі - ЄАІС Держмитслужби).

Порядок регламентує стадії та етапи виконання робіт з розроблення й упровадження програмно-інформаційних комплексів (далі - ПІК), послідовність їх виконання, визначає результати виконання кожного з етапів і відповідальність виконавців.

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

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

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

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

Усі роботи з розроблення та впровадження ПІК повинні виконуватися з обов'язковим дотриманням вимог цього Порядку.

1.5. Функціональний склад групи спеціалістів:

керівник інформаційних систем;

керівник проекту;

системний архітектор;

адміністратор даних;

адміністратор баз даних;

програміст;

технічний персонал;

секретар.

1.6. Усі призначені на конкретну функціональну роль у групі з розроблення та впровадження ПІК спеціалісти повинні знати свої функції в обсязі, визначеному в додатку 1 до цього Порядку, а також відповідати кваліфікаційним вимогам, які висунуто до цих функціональних ролей.

2.1. Стадії робіт зі створення ПІК і строки їх виконання установлюються наказом або розпорядженням на виконання робіт і Планом-графіком розроблення та впровадження ПІК та повинні включати:

технічне завдання;

технічний проект;

робочий проект;

впровадження ПІК.

Під час розроблення та впровадження ПІК створюється технічна документація (зміст та вимоги до її оформлення викладено в додатку 2 до цього Порядку).

Залежно від специфіки створюваного ПІК і умов його створення допускається:

об'єднувати стадії;

виконувати окремими етапами роботи до завершення робіт за попередніми стадіями;

паралельне в часі виконання за етапами робіт;

включення нових етапів робіт,

що обов'язково повинно бути відображено в наказі або розпорядженні на виконання робіт і в План-графіку розроблення та впровадження ПІК.

Типовий План-графік розроблення та впровадження ПІК наведено в додатку 3.

У разі наявності на об'єкті автоматизації складних технологічних процесів, перелік робіт із створення ПІК при необхідності може включати в себе розробку Технологічних схем процесів, що підлягають автоматизації в рамках даної задачі.

2.2. Стадії робіт із створення ПІК

2.2.1. Технічне завдання

Зміст робіт:

збір даних про об'єкт автоматизації та види його діяльності;

оцінка якості функціонування об'єкта, виявлення проблем, рішення яких можливе засобами ПІК;

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

оцінка (техніко-економічне обґрунтування і т.і.) та мета створення ПІК;

підготовка вихідних даних для формування вимог користувача до ПІК (характеристика об'єкта, опис вимог до ПІК, обмеження допустимих затрат на розробку, введення в дію та експлуатацію, ефект, який очікується від ПІК, умови створення і функціонування ПІК);

опрацювання альтернативних варіантів концепції створюваного ПІК та планів їх реалізації;

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

оцінка переваг і недоліків кожного варіанту;

співставлення вимог користувача та характеристик запропонованих варіантів та вибір оптимального варіанту;

визначення порядку оцінки якості і умов приймання ПІК;

оцінка ефектів, які отримуються користувачами від використання ПІК;

формулювання Вимог користувача до ПІК та оформлення Специфікації вимог користувача (User Requirements Specification) за формою, наведеною в додатку 2 до цього Порядку.

Вимоги користувача та Функціональні вимоги, які з них витікають, діляться на:

типові вимоги, загальні для всіх програмно-інформаційних комплексів, які розробляються в рамках ЄАІС Держмитслужби;

вимоги, які визначаються конкретною задачею, що розв'язується.

Етапи робіт:

1) Розроблення Специфікації вимог користувача.

2) Розроблення Специфікації функціональних вимог.

3) Розроблення Технічного завдання.

4) Складання План-графіку розроблення та впровадження ПІК.

Етапи виконання робіт, вхідна і вихідна інформація (у загальному випадку) наведені в додатку 4 до цього Порядку.

1) Розроблення Специфікації вимог користувача є першим етапом розроблення Технічного завдання, на якому виконуються такі роботи:

а) вивчення нормативних документів, які є підставою для розроблення ПІК;

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

визначення основної мети розроблення та призначення ПІК;

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

визначення у рамках конкретної задачі аналізу та обробки даних за оперативними запитами;

визначення вимог до вхідної та вихідної інформації (види екранних форм, текстових файлів, форм друкованих документів);

визначення форм звітності;

визначення повноважень доступу користувачів до інформації;

в) Визначення вимог до вхідного та вихідного інтерфейсів (ручний режим вводу інформації, режим вводу інформації у форматі передачі на дискетах чи каналами електронної пошти у вигляді файлів формату електронних повідомлень або засобами відомчої телекомунікаційної мережі ЄАІС Держмитслужби);

г) Визначення функціональних вимог (перелік функцій ПІК та умов пошуку інформації);

д) Визначення експлуатаційних вимог (визначення вимог, які доповнюють загальні типові експлуатаційні вимоги до інформаційної системи архітектури типу Клієнт-Сервер);

е) Визначення проектних обмежень у даній задачі в разі їх наявності;

є) Визначення додаткових вимог до основних характеристик (продуктивності) даної задачі, які обумовлені застосуванням апаратних та системних програмних засобів;

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

2) Розроблення Специфікації функціональних вимог є наступним етапом розроблення Технічного завдання. Специфікація функціональних вимог базується на вимогах користувача, наведених у Специфікації вимог користувача, визначає (формулює) перелік функціональних вимог до ПІК та подає їх у формалізованому вигляді.

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

3) Розроблення Технічного завдання є наступним етапом, на якому виконуються такі роботи:

попереднє визначення вимог до складу та параметрів технічних та системних програмних засобів з подальшим обговоренням та викладенням у Технічному проекті;

визначення вимог до алгоритму реалізації:

а) визначення об'єктів комплексу програм та схеми їх взаємозв'язку;

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

в) визначення критеріїв (умов пошуку), за якими ведеться робота з базами даних;

г) визначення екранних форм (вхідних та вихідних) для роботи з базами даних;

д) попереднє визначення умовно-постійних (системних) та умовно-змінних (для певної задачі) довідників;

е) визначення вхідних даних для наповнення (завантаження) умовно-змінних довідників (опис і характеристика вхідних даних та шляхи їх формування);

є) визначення форм звітів (екранних та в друкованому вигляді);

ж) визначення вхідних та вихідних даних для звітів (опис і характеристика даних та шляхи їх формування);

визначення додаткових (відмінних від типових) вимог до програмної документації;

визначення додаткових (відмінних від типових) вимог до порядку контролю та приймання ПІК.

4) Складання План-графіку розроблення та впровадження ПІК є завершальним етапом розроблення Технічного завдання, на якому виконуються такі роботи:

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

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

визначення строків виконання (початку та завершення) для всіх стадій та етапів;

визначення результатів виконання кожної з стадій та етапів розроблення.

2.2.2. Технічний проект

Зміст робіт:

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

При необхідності розроблення Технологічних схем виконуються такі роботи:

1) визначення загального опису технології по задачі:

перелік учасників (суб'єктів) технологічного процесу;

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

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

2) розроблення інформаційної взаємодії локальної (центральної) бази даних із зовнішніми та внутрішніми контрагентами.

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

Етапи робіт:

1) Розроблення Архітектури системи.

2) Моделювання процесів (модулів).

3) Моделювання даних.

4) Проектування бази даних.

5) Проектування мета-даних.

Види вхідної та вихідної інформації на етапах (загалом) наведено в додатку 5 до цього Порядку.

1) Розроблення Архітектури системи є першим етапом Технічного проекту, на якому виконуються такі роботи:

а) розроблення Інфраструктури системи на основі Специфікації вимог користувача та Специфікації функціональних вимог, а саме:

- визначення структури технічних і програмних засобів;

- визначення необхідного забезпечення мережі ПІК.

На цьому етапі визначаються такі елементи системи Клієнт-Сервер:

- клієнти;

- сервери;

- мережі;

- адміністрування системи.

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

в) визначення Виробничих стандартів, які включають:

засоби розроблення;

виробничі стандарти, принципи розроблення та керівні (нормативні) документи;

погодження про імена для всіх компонентів системи:

- імена модулів (процесів);

- імена баз даних;

- імена файлів даних;

- імена системних повідомлень;

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

г) визначення Основних операцій, тобто принципів функціонування системи, які включають:

- принципи проектування;

- системні функції;

- погодження з Специфікацією функціональних вимог.

д) складання Програми тестування ПІК, яка повинна включати тестування всіх функцій системи, описаних в попередньому розділі і складається з:

- тесту продуктивності;

- тесту з реальними значеннями даних;

- тесту всіх міжпроцесних зв'язків.

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

Верхній рівень діаграми - контекстна діаграма, яка показує головні процеси системи Клієнт-Сервер. Нижні рівні ієрархії містять елементарні процеси (модулі). Типова ієрархія повинна будуватись з двох-трьох рівнів.

Діаграми потоків даних повинні містити опис:

потоків даних;

елементарних процесів;

сховищ даних;

зовнішніх сутностей;

фізичних ресурсів.

Побудова Діаграм потоків даних виконується за стандартом SSADM, який базується на п'яти конструкціях:

потоки даних - показують напрямок (маршрут) переміщення даних з одної точки системи до другої;

процеси - перетворюють, змінюють вхідні потоки даних у вихідні потоки даних;

сховища даних - описують інформаційні архіви, які можуть зображати постійні/тимчасові та комп'ютерні/фізичні сховища;

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

фізичні ресурси - являють собою окремі елементи (сутності), які взаємодіють з інформаційною системою, такі як друковані звіти, документи, форми і т.п. та корисні для відображення:

вагомих потоків та станів;

результатів діалогів з користувачем;

реальної уяви про систему.

Існують два підходи (методи, принципи) до моделювання процесів:

спеціальний;

загальний.

Ці підходи повинні застосовуватись разом, результатом застосування обох методів повинна бути концептуальна модель процесів.

Спеціальний метод, при якому:

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

виводиться (будується) "логічна" модель з "фізичної" моделі;

деталізується "логічна" модель доповненням нових вимог з Функціональної специфікації;

Результатом є концептуальна модель потрібної системи.

Загальний (основний) метод, при якому будується "загальна" модель, що базується на:

Функціональній специфікації;

розумінні типу системи;

розумінні організації (об'єкта автоматизації)

деталізації "загальної" моделі доповненням нових вимог з Функціональної специфікації;

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

Результатом є Концептуальна модель потрібної системи.

Завершення моделювання процесів полягає у тому, що:

Концептуальна модель повинна бути відображена в інфраструктурі системи для побудови Внутрішньої моделі;

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

Цей процес ітеративний, він може вимагати модифікації моделей на всіх рівнях.

Практичне моделювання процесів повинно здійснюватись у відповідності з інструкціями засобів автоматизації, які використовуються при розробці, наприклад, "Designer 2000".

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

Моделювання даних, яке базується на E-R моделі, описано в публікації Peter P. Chen "The Entity-Relationship Model - toward a Unified of Data" (March 1976).

Практичне моделювання даних повинно здійснюватись у відповідності з інструкціями засобів автоматизації, які використовуються при розробці, наприклад - "Designer 2000".

4) Проектування бази даних базується на нормалізованій Концептуальній логічній моделі та являє собою перетворення логічної моделі в фізичну модель бази даних, тобто проектування серверної частини ПІК на основі розроблених на попередніх стадіях проектування описів процесів, діаграм потоків даних і E-R діаграм.

Це перетворення включає:

визначення первинних джерел;

відображення сутностей в таблиці;

відображення атрибутів сутностей до колонок;

відображення відносин до зовнішніх джерел;

опис структур таблиць;

створення скриптів (файлів формату SQL з описом таблиць) та генерацію за ними фізичних таблиць бази даних;

опис тригерів;

створення при необхідності серверних процедур і оглядів користувача.

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

5) Проектування мета-даних, їх ретельний опис є критичною (ключовою) частиною проектування систем Клієнт-Сервер.

Мета-дані використовуються системою для адміністративних і управляючих режимів роботи системи і повинні містити в собі інформацію:

- про структуру бази даних;

- фізичні характеристики таблиць (перелік імен, типів та розмірів компонентів, джерела інформації з вказівкою імен таблиць БД та їх полів, опису умов перевірки).

Склад документації, що оформляється при розробці Технічного проекту, наведено в додатку 2 цього Порядку.

Вимоги до Інфраструктури інформаційної системи архітектури типу Клієнт-Сервер поділяються на:

типові вимоги до інфраструктури, спільні для всіх програмно-інформаційних комплексів, які розробляються в рамках ЄАІС Держмитслужби;

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

2.2.3. Робочий проект

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

Етапи робіт:

1) Проектування модулів.

2) Програмування модулів.

3) Тестування модулів.

4) Програмування системи в цілому.

5) Розроблення документації.

6) Тестування системи в цілому (внутрішнє).

7) Тестування системи в цілому (у замовника).

Етапи виконання робіт, вхідну і вихідну інформацію (у загальному випадку) наведено в додатку 6 до цього Порядку.

2.2.4. Впровадження проекту

Етапи робіт:

1) дослідна експлуатація.

2) передача до постійної експлуатації.

Етапи виконання робіт, вхідну і вихідну інформацію (у загальному випадку) наведено в додатку 7 до цього Порядку.

Загальні вимоги до оформлення документів:

заголовки документів повинні бути на окремому листі;

вимоги у документах повинні бути викладені по можливості коротко та просто;

складні (комплексні) вимоги повинні бути детально описані;

повинні бути використані зразки (макети, прототипи) інтерфейсів (наприклад: екранні форми) та форм звітів або наведені посилання на них;

повинні бути максимально використані можливості посилань на інші документи.

Специфікація вимог користувача визначає (формулює) перелік вимог користувача до ПІК та подає їх у формалізованому вигляді.

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

1) Вступ, у якому наводиться короткий опис призначення документа, термінів та скорочень.

2) Посилання, у якому наводиться опис прикладених документів чи посилання на документів, що містять корисну інформацію.

3) Керівні вимоги, у якому описуються загальні вимоги до ПІК;

4) Вимоги до інтерфейсу, у якому описуються вимоги до:

- вхідного інтерфейсу;

- вихідного інтерфейсу;

- інтерфейсу користувача.

5) Функціональні вимоги.

6) Експлуатаційні вимоги.

7) Проектні обмеження.

8) Вимоги до основних характеристик (продуктивності).

9) Вимоги до документації.

Кожна вимога повинна мати свій унікальний складений номер такої форми:

URS.X.nnn

де:

URS означає User Requirement Specification;

X має одно з таких значень:

M - для керівних (керуючих) вимог (наприклад: місячний звіт повинен бути готовим на 5-й робочий день місяця);

I - для вимог до інтерфейсу;

F - для функціональних вимог;

O - для експлуатаційних вимог;

C - для обмежень проектування (наприклад: дані повинні бути доступними 5 років);

P - для вимог до продуктивності (наприклад: час обробки запиту....)

D - для вимог до документації;

nnn - порядковий номер вимоги (001, 002... ).

Специфікація функціональних вимог базується на вимогах користувача, наведених у Специфікації вимог користувача, визначає (формулює) перелік функціональних вимог до ПІК та подає їх у формалізованому вигляді.

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

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

1) Вступ, у якому наводиться короткий опис призначення документа, термінів та скорочень.

2) Посилання, у якому наводиться опис прикладених документів чи посилання на документи, що містять корисну інформацію.

3) Керівні вимоги, в якому описуються загальні вимоги до ПІК.

4) Вимоги до інтерфейсу, в якому описуються вимоги до:

- вхідного інтерфейсу;

- вихідного інтерфейсу;

- інтерфейсу користувача.

5) Функціональні вимоги.