Міжвідомчі інформаційно-телекомунікаційні системи, як результат реалізації цільових програм щодо обміну інформаційними ресурсами між державними органами
Проводиться аналіз детальної декомпозиції процесу обґрунтування потреб у технічних, програмних та фінансових ресурсах при створенні інтегрованих міжвідомчих інформаційно-телекомунікаційних систем у межах державних цільових програм для обміну інформаційними ресурсами між відомчими інформаційними сист...
Збережено в:
Дата: | 2009 |
---|---|
Автори: | , |
Формат: | Стаття |
Мова: | Ukrainian |
Опубліковано: |
Інститут програмних систем НАН України
2009
|
Теми: | |
Онлайн доступ: | http://dspace.nbuv.gov.ua/handle/123456789/4415 |
Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
Цитувати: | Міжвідомчі інформаційно-телекомунікаційні системи, як результат реалізації цільових програм щодо обміну інформаційними ресурсами між державними органами / В.А. Алексеєв , В.С. Терещенко // Пробл. програмув. — 2009. — № 2. — С. 50-66. — Бібліогр.: 22 назв. — укр. |
Репозитарії
Digital Library of Periodicals of National Academy of Sciences of Ukraineid |
irk-123456789-4415 |
---|---|
record_format |
dspace |
spelling |
irk-123456789-44152009-11-03T12:00:32Z Міжвідомчі інформаційно-телекомунікаційні системи, як результат реалізації цільових програм щодо обміну інформаційними ресурсами між державними органами Алексеєв, В.А. Терещенко, В.С. Електронний уряд Проводиться аналіз детальної декомпозиції процесу обґрунтування потреб у технічних, програмних та фінансових ресурсах при створенні інтегрованих міжвідомчих інформаційно-телекомунікаційних систем у межах державних цільових програм для обміну інформаційними ресурсами між відомчими інформаційними системами зацікавлених відомств.----------------------- Проводится анализ детальной декомпозиции процесса обоснования потребности в технических, программных и финансовых ресурсах при создании интегрированных межведомственных информационно–телекоммуникационных систем в рамках государственных целевых программ для обмена информационными ресурсами между ведомственными информационными системами заинтересованных ведомств.------------------ The analysis of detailed decomposition of the process of a substantiation of necessity in technical, program will be carried out(spent) and financial resources at creation integrated interdepartmental is informational - telecommunication of systems within the framework of state target pro-grams for exchange by information resources between departmental information systems of the interested departments. 2009 Article Міжвідомчі інформаційно-телекомунікаційні системи, як результат реалізації цільових програм щодо обміну інформаційними ресурсами між державними органами / В.А. Алексеєв , В.С. Терещенко // Пробл. програмув. — 2009. — № 2. — С. 50-66. — Бібліогр.: 22 назв. — укр. 1727-4907 http://dspace.nbuv.gov.ua/handle/123456789/4415 681.3 uk Інститут програмних систем НАН України |
institution |
Digital Library of Periodicals of National Academy of Sciences of Ukraine |
collection |
DSpace DC |
language |
Ukrainian |
topic |
Електронний уряд Електронний уряд |
spellingShingle |
Електронний уряд Електронний уряд Алексеєв, В.А. Терещенко, В.С. Міжвідомчі інформаційно-телекомунікаційні системи, як результат реалізації цільових програм щодо обміну інформаційними ресурсами між державними органами |
description |
Проводиться аналіз детальної декомпозиції процесу обґрунтування потреб у технічних, програмних та фінансових ресурсах при створенні інтегрованих міжвідомчих інформаційно-телекомунікаційних систем у межах державних цільових програм для обміну інформаційними ресурсами між відомчими інформаційними системами зацікавлених відомств.----------------------- |
format |
Article |
author |
Алексеєв, В.А. Терещенко, В.С. |
author_facet |
Алексеєв, В.А. Терещенко, В.С. |
author_sort |
Алексеєв, В.А. |
title |
Міжвідомчі інформаційно-телекомунікаційні системи, як результат реалізації цільових програм щодо обміну інформаційними ресурсами між державними органами |
title_short |
Міжвідомчі інформаційно-телекомунікаційні системи, як результат реалізації цільових програм щодо обміну інформаційними ресурсами між державними органами |
title_full |
Міжвідомчі інформаційно-телекомунікаційні системи, як результат реалізації цільових програм щодо обміну інформаційними ресурсами між державними органами |
title_fullStr |
Міжвідомчі інформаційно-телекомунікаційні системи, як результат реалізації цільових програм щодо обміну інформаційними ресурсами між державними органами |
title_full_unstemmed |
Міжвідомчі інформаційно-телекомунікаційні системи, як результат реалізації цільових програм щодо обміну інформаційними ресурсами між державними органами |
title_sort |
міжвідомчі інформаційно-телекомунікаційні системи, як результат реалізації цільових програм щодо обміну інформаційними ресурсами між державними органами |
publisher |
Інститут програмних систем НАН України |
publishDate |
2009 |
topic_facet |
Електронний уряд |
url |
http://dspace.nbuv.gov.ua/handle/123456789/4415 |
citation_txt |
Міжвідомчі інформаційно-телекомунікаційні системи, як результат реалізації цільових програм щодо обміну інформаційними ресурсами між державними органами / В.А. Алексеєв , В.С. Терещенко // Пробл. програмув. — 2009. — № 2. — С. 50-66. — Бібліогр.: 22 назв. — укр. |
work_keys_str_mv |
AT alekseêvva mížvídomčíínformacíjnotelekomuníkacíjnísistemiâkrezulʹtatrealízacíícílʹovihprogramŝodoobmínuínformacíjnimiresursamimížderžavnimiorganami AT tereŝenkovs mížvídomčíínformacíjnotelekomuníkacíjnísistemiâkrezulʹtatrealízacíícílʹovihprogramŝodoobmínuínformacíjnimiresursamimížderžavnimiorganami |
first_indexed |
2025-07-02T07:39:58Z |
last_indexed |
2025-07-02T07:39:58Z |
_version_ |
1836520045200539648 |
fulltext |
Електронний уряд
50
УДК 681.3
В.А. Алексеєв, В.С. Терещенко
МІЖВІДОМЧІ ІНФОРМАЦІЙНО-ТЕЛЕКОМУНІКАЦІЙНІ СИСТЕМИ,
ЯК РЕЗУЛЬТАТ РЕАЛІЗАЦІЇ ЦІЛЬОВИХ ПРОГРАМ ЩОДО ОБМІНУ ІНФО-
РМАЦІЙНИМИ РЕСУРСАМИ МІЖ ДЕРЖАВНИМИ ОРГАНАМИ
Проводиться аналіз детальної декомпозиції процесу обґрунтування потреб у технічних, про-
грамних та фінансових ресурсах при створенні інтегрованих міжвідомчих інформаційно-
телекомунікаційних систем у межах державних цільових програм для обміну інформаційними
ресурсами між відомчими інформаційними системами зацікавлених відомств.
Вступ
Одним з пріоритетних завдань щодо
розвитку інформаційного суспільства в
нашій країні є надання громадянам та
юридичним особам інформаційних та ін-
ших послуг шляхом використання елект-
ронної інформаційної системи "Електро-
нний Уряд", яка має забезпечувати інфор-
маційну взаємодію органів виконавчої
влади між собою, з громадянами та юри-
дичними особами на основі сучасних ін-
формаційних технологій [1].
На поточний час інформаційна вза-
ємодія органів виконавчої влади між со-
бою потребує, зокрема, вирішення інфор-
маційних задач з питань забезпечення:
• взаємодії суб’єктів державного
фінансового моніторингу, правоохоронних
органів, інших державних органів з метою
створення єдиного інформаційного прос-
тору для забезпечення комплексного ана-
лізу інформації про обіг коштів, здобутих
злочинним шляхом, виявлення механізмів
їх легалізації, запобігання відмиванню (ле-
галізації) таких доходів, розробки заходів
протидії таким явищам;
• діяльності центральних органів
державної влади України щодо реалізації
державної політики у сфері контролю за
міграційними процесами на державному
кордоні України;
• боротьби із злочинністю, а саме:
з забезпечення створення умов для поліп-
шення координації організаційних, профі-
лактичних, оперативно-розшукових захо-
дів, а також підвищення ефективності ін-
формаційно-аналітичного забезпечення
правоохоронної діяльності за рахунок
удосконалення інформаційної взаємодії
між зацікавленими відомствами.
Реалізація інформаційної взаємодії
між зацікавленими відомствами для вирі-
шення цих проблем можлива шляхом
створення та використання сучасних за-
хищених інтегрованих міжвідомчих ін-
формаційно-телекомунікаційних систем
(ІМІТС) і проведення стандартизованих
(уніфікованих) процедур обміну інформа-
цією між відомчими інформаційними сис-
темами (ВІС), що належать суб’єктам
ІМІТС – вже згаданим зацікавленим ві-
домствам. По суті, ІМІТС – це сукупність
взаємопов'язаних нормативно-правових,
організаційно-розпорядчих заходів, про-
грамно-технічних та телекомунікаційних
засобів, що забезпечують процеси збору,
обробки, накопичення, аналізу та збері-
гання інформації визначеної сфери суспі-
льного життя шляхом об’єднання відповід-
них інформаційних ресурсів баз даних
(БД) ВІС.
Структури ІМІТС детально розгля-
нуті у багатьох роботах, зокрема в [2, 3, 4,
5], тому розглядати їх знову нема потреби,
але нагадаємо, що ІМІТС створюється
шляхом об’єднання інформаційних ресур-
сів БД ВІС через відповідні відомчі підси-
стеми (ВП) ІМІТС, спеціально створені
для забезпечення автоматизованого досту-
пу до ВІС шляхом застосування систем
інформаційної взаємодії. Обмін інформа-
ційними ресурсами між ВП здійснюється
через центральну підсистему (ЦП) ІМІТС
за допомогою спеціальної телекомуніка-
ційної системи (СТМ), яка може бути роз-
горнута на базі існуючих мереж зв'язку,
© В.А. Алексеєв, В.С. Терещенко, 2009
ISSN 1727-4907. Проблеми програмування. 2009. № 2
Електронний уряд
51
зокрема, на базі мереж Національної сис-
теми конфіденційного зв’язку (НСКЗ). Та-
ким чином, складовими ІМІТС є ВП, об'-
єднані з ЦП за допомогою СТМ. ВІС не є
складовою ІМІТС, але є безпосереднім
учасником процесу обміну інформаційни-
ми ресурсами і для цього потребує відпо-
відні програмно-апаратні засоби.
У якості інформаційних ресурсів
ІМІТС (далі – ІР) визначаються групи вза-
ємопов'язаних задокументованих одиниць
інформації, які об'єднані за певними озна-
ками у ВІС державних органів та викорис-
товуються в процесі обміну інформацією
між суб'єктами ІМІТС, тобто пересилання
(переміщення) інформаційного об'єкта з
одного компонента інформаційної мережі
в інший засобами мережі [6]. Домовимось,
інформаційні ресурси в межах простору
ВІС-ВП називати інформаційними об'єк-
тами. Вони можуть бути у вигляді записів
у таблицях баз даних (сильнозв'язані інфо-
рмаційні об'єкти), файлів або транспорт-
них файлів (слабкозв'язані інформаційні
об'єкти), на які ще не "накладено" елект-
ронний цифровий підпис (ЕЦП). Транспо-
ртні файли з ЕЦП, які використовуються
для передачі засобами СТМ, є електрон-
ними документами.
Електронний документ – документ,
інформація в якому зафіксована у вигляді
електронних даних, включаючи електрон-
ний підпис – обов'язковий реквізит, який
використовується для ідентифікації автора
та/або підписувача електронного докумен-
та іншими суб'єктами електронного доку-
ментообігу. Накладанням електронного
підпису завершується створення електро-
нного документа [7].
Інформація відомств – суб'єктів
ІМІТС – створена на кошти державного
бюджету, тому є державною власністю [8].
Таким чином, у складових вищеописаної
ІМІТС обробляється інформація, яка є
державною власністю. Інформація, яка є
власністю держави, має оброблятися в ІТС
із застосуванням комплексної системи за-
хисту інформації (КСЗІ) з підтвердженою
відповідністю [9]. Такі КСЗІ, в загальному
випадку, мають забезпечувати захист ін-
формації на всіх етапах її обробки від
будь-яких загроз інформації [10], але най-
більш поширеними їх властивостями є за-
безпечення захисту від несанкціонованого
доступу згідно вимог критеріїв конфіден-
ційності, цілісності, доступності та спо-
стереженості [11] та забезпечення цілісно-
сті інформаційних ресурсів, що пов'язано з
категорією використовуваної у ІМІТС ін-
формації. Для цього такі КСЗІ можуть
включати, зокрема, механізми розмежу-
вання доступу до інформації, механізми
криптографічного захисту ("накладання"
та "зняття" ЕЦП) та антивірусного захисту
щодо вимог нормативних документів сфе-
ри технічного захисту інформації (ТЗІ).
Одною із вимог такої КСЗІ ІМІТС може
бути фізичний розрив між ВІС та ВП при
зберіганні обміну між ними за допомогою
змінних носіїв.
Правовим та фінансовим підґрун-
тям для створення таких ІМІТС, як прави-
ло, виступають державні цільові програми
(ДЦП) або інші рішення з боку Кабінету
Міністрів. Щодо перелічених на початку
статті завдань, то вони, наприклад, вирі-
шуються в межах:
• державної програми протидії ле-
галізації (відмиванню) доходів, одержаних
злочинним шляхом [12] та Програми ство-
рення Єдиної державної інформаційної си-
стеми у сфері запобігання та протидії ле-
галізації (відмиванню) доходів, одержаних
злочинним шляхом, і фінансуванню теро-
ризму [13];
• плану заходів із створення інтег-
рованої міжвідомчої інформаційно-
телекомуніка-ційної системи щодо кон-
тролю осіб, транспортних засобів та ван-
тажів, які перетинають державний кордон
[14];
• державної програми інформацій-
но-телекомунікаційного забезпечення пра-
воохоронних органів, діяльність яких по-
в'язана з боротьбою із злочинністю [15].
Актуальність розроблення і вико-
нання таких ДЦП обумовлена необхідніс-
тю переходу на принципово новий рівень
інформаційно-телекомунікаційного забез-
печення зацікавлених відомств, більш
ефективного використання інформаційних
ресурсів для реалізації державної політики
у зазначеній сфері. Так, у межах перших
двох з перелічених ДЦП створено і функ-
Електронний уряд
52
ціонують відповідні ІМІТС, які згодом
можуть стати складовими електронної ін-
формаційної системи "Електронний Уряд":
• єдина державна інформаційна
система у сфері запобігання та протидії
легалізації (відмиванню) доходів, одержа-
них злочинним шляхом, і фінансуванню
тероризму (ЄІС ФМ) [16];
• інтегрована міжвідомча інфор-
маційно-телекомунікаційна система щодо
контролю осіб, транспортних засобів та
вантажів, які перетинають державний
кордон України (система "Аркан") [17, 18].
Третя з перелічених ДЦП знахо-
диться на стадії визначення потреб у тех-
нічних, програмних та фінансових ресур-
сах при створенні відповідної ІМІТС пра-
воохоронних органів – ІМІТС ПО.
Кожного разу, приступаючи до роз-
робки подібних ДЦП, постають проблеми
визначення потреб у ресурсах для її реалі-
зації. Вони не такі прості, як може здатися
на перший погляд, тому проблемам визна-
чення шляхів щодо розрахунку потреб у
ресурсах та їхніх витрат на реалізацію
ДЦП із створення ІМІТС, призначеної для
обміну обумовленим переліком інформа-
ційних ресурсів між ВІС суб’єктів ІМІТС
на прикладі ІМІТС ПО і присвячена дана
робота.
1. Обґрунтування методики
визначення потреб та витрат при
створенні ІМІТС
Визначення витрат на розробку
ІМІТС може здійснюватись з використан-
ням значної кількості методів: експертних
оцінок, оцінювання «згори-вниз», оціню-
вання «знизу-вгору», аналогій, математич-
них моделей, нейронних та байєсівських
мереж тощо. Всі вони мають свої переваги
та свої вади перед іншими, а тому кожний
з цих методів має залучатись до визначен-
ня витрат на етапі, де його позитивні ха-
рактеристики найбільше проявляють себе.
Перевагами методів експертних
оцінок є урахування досвіду попередніх
розробок, а недолік – велика залежність від
компетентності експертів. Тому ці методи
доцільно застосовувати для оцінки розмі-
рів та трудовитрат у тих випадках, коли
відсутні історичні дані про відповідні ха-
рактеристики у минулих проектах [19].
Перевагами методу оцінювання
«згори-вниз» є можливість ретельного
оцінювання загальносистемних робіт,
зв’язаних з інтеграцією, документуванням,
контрольними функціями, керуванням
конфігурацією та ін. Однак, метод приво-
дить до недооцінки компонентів на нижніх
рівнях проекту, а, крім того, не містить
механізмів для настроювання параметрів
оцінок у ході життєвого циклу програмних
систем [19].
Перевагами методу оцінювання
«знизу-вгору» є можливість ретельного
оцінювання кожного окремого програмно-
го компонента та подальше комбінування
результатів для отримання оцінок всього
проекту програмної системи, а недоліками
– недооцінка загальносистемних робіт, ве-
лика трудомісткість та складність застосу-
вання на ранніх стадіях життєвого циклу
через брак даних [19].
Перевагами методу аналогій є ви-
користання реальних даних проектів і на-
копиченого досвіду розробки та оцінюван-
ня для співставлення характеристик за-
пропонованого до розробки проекту про-
грамної системи та завершених програм-
них проектів-аналогів. Оцінка за ана-
логами можлива як на рівні всього проекту
програмної системи, так і на рівні окремих
її компонентів. Недоліком методу є склад-
ність застосування, яка обумовлена важкі-
стю виявлення та оцінки відмін нового
проекту від завершених проектів. Точність
метода залежить від достовірності даних
про аналоги [19]. Тому цей метод доцільно
використовувати при наявності повних да-
них про проект-аналог, і найбільш слуш-
ною ситуацією можна вважати, якщо та-
кий проект-аналог є попередньою розроб-
кою організації – претендента на розроб-
нику нової ІМІТС.
Перевагами методів математичного
моделювання є можливість повторного
оцінювання (виконання розрахунків за мо-
делями), простота модифікації вхідних да-
них та настроювання математичної залеж-
ності з урахуванням умов розробки кон-
Електронний уряд
53
кретних проектів (розраховані значення
об’єму програмної системи та кількості
виконуваних нею функцій, а також такі
важливі фактори, як мова програмування,
методологія проектування, досвід розроб-
ників та ін.). Однак, результати оцінок за
існуючими моделями проблематичні при
оцінюванні проектів, що розроблюються за
новими технологіями та в нових умовах
[19].
Автори у своїй роботі віддали пере-
вагу застосуванню методів експертних
оцінок, аналогій та математичного моде-
лювання, використовуючи для цього від-
повідний інструментарій.
Перш ніж визначати потреби в ре-
сурсах для створення ІМІТС треба визна-
читись з її функціональним завданням, пе-
реліком її функцій та технологій їхньої ре-
алізації. Для цього проводиться обстежен-
ня потенційних суб’єктів такої ІМІТС на
предмет їхньої потреби в обміні інформа-
ційними ресурсами в межах цієї системи та
застосуванні найбільш придатних техноло-
гій для цього, використовуючи окремі по-
зиції методу експертних оцінок. На базі
цих даних визначається система-прототип
серед існуючих систем аналогічного чи
близького призначення, використовуючи
метод аналогій. Характеристики системи-
прототипу та відомості щодо процесу її
створення дадуть змогу визначити перелік
та структурну декомпозицію робіт з її
створення та відносний розподіл потреб
ресурсів при створенні ІМІТС, знову вико-
ристовуючи метод експертних оцінок. А
це, в свою чергу, дасть змогу визначити за
допомогою математичних моделей та від-
повідного програмного інструментарію
витрати на розробку ІМІТС.
Таким чином, методика визначення
потреб при створенні ІМІТС має базува-
тись на різноманітних підходах, що будуть
описані далі у межах наступних етапів ро-
біт:
1) визначення функціонального за-
вдання та функцій створюваної ІМІТС як
результат обстеження потреб її потенцій-
них суб’єктів у обміні інформаційними ре-
сурсами та необхідними інформаційними
технологіями при цьому;
2) визначення кількості та переліку
інформаційних ресурсів для обміну між
суб'єктами ІМІТС;
3) визначення прототипу ІМІТС з
переліку вже існуючих систем-аналогів;
4) структурна декомпозиція робіт
та відносний розподіл потреб ресурсів при
створенні ІМІТС на основі інформації про
систему-прототип;
5) визначення витрат на розробку
ІМІТС за допомогою існуючого програм-
ного інструментарію.
2. Визначення функціонального
завдання та функцій створюваної
ІМІТС
Цільовою функцією створюваної
ІМІТС є забезпечення обміну інформацій-
ними ресурсами між ВІС суб'єктів ІМІТС
за допомогою відповідних програмно-
апаратних засобів ІМІТС та типових тех-
нологій обміну інформацією.
Такими типовими інформаційними
технологіями на даний час визнані:
1) "повідомлення" – процес фор-
мування у ВІС суб’єкта ІМІТС визначено-
го набору даних власного інформаційного
ресурсу у вигляді транспортного файлу
(ТФ), “накладання” ЕЦП та пересилання
електронного документа (ЕД) за допомо-
гою складових ІМІТС до ВІС іншого
суб’єкта ІМІТС для оновлення або попов-
нення її інформаційних ресурсів;
2) "запит/відповідь" – процес
включає дві фази:
- формування у ВІС суб’єкта ІМІТС
запиту (набору критеріїв пошуку інфор-
мації) у вигляді ТФ, “накладання” ЕЦП та
надсилання ЕД за допомогою складових
ІМІТС до ВІС інших суб’єктів ІМІТС –
власників інформаційних ресурсів;
- формування у ВІС суб’єкта ІМІТС
– власника інформаційних ресурсів, набо-
ру даних, який містить відповідь на запит,
у вигляді ТФ, “накладання” ЕЦП та надси-
лання ЕД за допомогою складових ІМІТС
до ВІС, від якої отримано запит;
3) "прямий доступ" до інформації
у базі даних – процес формування за до-
помогою складових ІМІТС запитів та
отримання відповідей у режимі безпосе-
Електронний уряд
54
реднього доступу до баз даних ВІС
суб’єктів ІМІТС – власників інформацій-
них ресурсів, або до дублікатів цих БД,
отриманих на відповідному сервері ІМІТС
за допомогою реплікації.
Технологія "прямого доступу" по-
требує вирішення як технічних проблем,
пов'язаних із захистом інформації, так і
організаційних. Не кожний власник інфо-
рмаційних ресурсів – потенційний суб'єкт
ІМІТС – згоден надавати можливості по-
рпатися у своїй базі даних та ще й давати
використовувати при цьому програмно-
технічні ресурси своєї ВІС іншій стороні.
Тому на даному етапі така технологія при
створенні ІМІТС не знайшла поширення, і
в межах цієї роботи у подальшому не роз-
глядатиметься.
Ураховуючи цільову функцію, ти-
пові інформаційні технології та вимоги за-
кону України [9] на кожного учасника ін-
формаційного обміну (ВІС, ВП, ЦП та
СТМ) припадають наступні функціональні
завдання:
1) для ВІС суб'єкта ІМІТС:
• для ВІС суб'єкта-відправника
(далі, відправника) – формування інфор-
маційного об'єкта ВІС в залежності від йо-
го призначення та застосованої технології
обміну інформацією у вигляді ТФ та пере-
несення його на змінний носій;
• для ВІС суб'єкта-отримувача (да-
лі, отримувача) – оброблення ТФ (зчиту-
вання та поповнення БД ВІС);
2) для ІМІТС:
• для ВП відправника – підготовка
ТФ до відправлення (зчитування, "накла-
дання" ЕЦП, завантаження ЕД в БД ВП);
• для ЦП та СТМ – оброблення ЕД
(вивантаження з БД ВП-відправника до БД
ЦП, а потім з БД ЦП до БД ВП-
отримувача);
• для ВП отримувача – оброблення
ЕД (вивантаження з БД ВП, "зняття" ЕЦП,
перенесення ТФ на змінний носій;
• для ІМІТС у цілому – захист ін-
формації ІМІТС на всіх етапах обробки та
пересилання інформаційних ресурсів у
межах ІМІТС за допомогою КСЗІ.
Реалізація цих завдань можлива за
допомогою наборів відповідних функцій,
які реалізуються як послідовність техноло-
гічних процесів, процедур та операцій, що
залежать від застосованої типової техноло-
гії обміну інформацією.
У залежності від задіяних у форму-
ванні ТФ програмних засобів ВІС або ВП
визначаються наступні типи технологічних
процесів оброблення даних:
1) тип "А" – оброблення даних за
технологічною схемою ВІС ↔ ВІС реалі-
зується як послідовність типових техноло-
гічних процедур відповідно для:
- "повідомлень" (підтип "А1")
(рис. 1);
- "запитів-відповідей" (підтип
"А2") (рис. 2);
2) тип "В"– оброблення даних за
технологічною схемою ВП ↔ ВІС реалізу-
ється як послідовність типових технологі-
чних процедур відповідно для:
- "повідомлень" (підтип "В1")
(рис. 3);
- "запитів-відповідей" (підтип
"В2") (рис. 4).
Слід зазначити, що технологічний
процес оновлення класифікаторів є фраг-
ментом підтипу "В2" (передача ТФ-
відповіді) і включає наступну послідов-
ність типових технологічних процедур об-
роблення даних: b → a → e.
Рис. 1. Процедури та операції при технології "повідомлення" (підтип "А1")
Електронний уряд
55
Рис. 2. Процедури та операції при технології "запит-відповідь" (підтип "А2")
Рис. 3. Процедури та операції при технології "повідомлення" (підтип "В1")
Рис. 4. Процедури та операції при технології "запит-відповідь" (підтип "В2")
Типові технологічні процедури (а,
b, c, d, e, f, g) для здійснення технологіч-
ного процесу в межах ІМІТС складаються
з відповідних типових технологічних опе-
рацій, тобто, є множинами відповідних
операцій, що призначені для реалізації фу-
нкціональних завдань за кожну складову
ІМІТС:
},,,,,{ 654321 aaaaaaa = – процедура
пересилання інформаційного об'єкта, де:
1a – накладання ЕЦП на ТФ (ВП);
2a – завантаження ЕД до БД/ВП
(ВП);
3a – вивантаження ЕД з БД/ВП до
БД/ЦП (ЦП);
4a – вивантаження ЕД з БД/ЦП до
БД/ВП (ЦП);
5a – вивантаження ЕД з БД/ВП
(ВП);
Електронний уряд
56
6a – зняття ЕЦП з ТФ (ВП);
}{ 1bb = – процедура зчитування ТФ
зі змінного носія;
}{ 1cc = – процедура запису ТФ на
змінний носій;
},{ 21 ddd = – процедура підготовки
інформаційного об'єкта до пересилання,
де:
1d – введення даних до БД/ВП;
2d – формування ТФ;
}{ 1ee = – процедура завантаження
даних ТФ-відповіді (ТФ-класифікатора) до
БД/ВП;
}{ 1ff = – процедура формування
ТФ-квитанції за результатами завантажен-
ня до БД/ВП даних ТФ;
}{ 1gg = – процедура завантаження
ТФ-квитанції до БД/ВП.
Треба зазначити, що процедура "а"
є типовою для ІМІТС. Вона відбувається за
будь-якого технологічного процесу. Її осо-
бливістю є те, що вона складається з опе-
рацій, які відбуваються у різних складових
ІМІТС. Це відповідним чином позначено
вище.
Типові технологічні процедури (А,
В, С ...) для здійснення технологічного
процесу в межах ВІС складаються з типо-
вих технологічних операцій, тобто, є мно-
жинами відповідних операцій, призначе-
них для реалізації функціональних завдань
у ВІС, як безпосередніх учасників обміну
інформацією:
},{ 21 AAA = – процедура підготов-
ки ТФ-повідомлення у ВІС відправника
повідомлення, де:
1A – операція формування ТФ-
повідомлення;
2A – операція запису ТФ-
повідомлення на змінний носій;
}{ 1BB = – процедура оброблення
ТФ-повідомлення у ВІС отримувача повід-
омлення;
},{ 21 CCC = – процедура підготов-
ки ТФ-квитанції у ВІС отримувача повід-
омлення, де:
1C – операція формування ТФ-
квитанції за результатами оброблення ТФ-
повідомлення;
2C – операція запису ТФ-квитанції
на змінний носій;
}{ 1DD = – процедура оброблення
ТФ-квитанції у ВІС відправника повідом-
лення;
},{ 21 EEE = – процедура підготов-
ки ТФ-запиту у ВІС відправника запиту,
де:
1E – операція формування ТФ-
запиту;
2E – операція запису ТФ-запиту на
змінний носій;
}{ 1FF = – процедура оброблення
ТФ-запиту у ВІС отримувача запиту;
},{ 21 GGG = – процедура підготов-
ки ТФ-відповіді у ВІС отримувача запиту,
де:
1G – операція формування ТФ-
відповіді;
2G – операція запису ТФ-відповіді
на змінний носій;
}{ 1HH = – процедура оброблення
ТФ-відповіді у ВІС відправника запиту;
},{ 21 III = – процедура підготовки
ТФ-квитанції у ВІС відправника запиту,
де:
1I – операція формування ТФ-
квитанції за результатами оброблення ТФ-
відповіді;
2I – операція запису ТФ-квитанції
на змінний носій;
}{ 1JJ = – процедура оброблення
ТФ-квитанції у ВІС отримувача запиту.
3. Визначення переліку ін-
формаційних ресурсів ІМІТС
Для реалізації визначених функціо-
нальних завдань та функцій необхідно,
перш за все, визначити перелік інформа-
ційних ресурсів, що підлягає обміну між
суб'єктами ІМІТС. Визначення такого пе-
реліку базується на результатах передпро-
ектного обстеження потенційних суб’єктів
такої ІМІТС.
Електронний уряд
57
Результат такого обстеження можна
представити у вигляді n-вимірної матриці
abcdM , кожний вимір якої визначається від-
повідною множиною:
– суб’єктів ІМІТС – I
iiaA 1}{ == ;
– інформаційних ресурсів, що зна-
ходяться в базах даних ВІС суб’єктів
ІМІТС, і підлягають взаємному обміну в
ІМІТС – Z
zzbB 1}{ == ;
– задіяних в ІМІТС технологій об-
міну інформаційними ресурсами –
X
xxcC 1}{ == та вектором Y
yydD 1}{ == , де
2=Y , елементи якого визначають етап
процесу обміну інформаційним ресурсом в
ІМІТС. Елемент yd при 1=y свідчить про
відправлення інформаційних ресурсів з
ВІС ia -го суб’єкта до ВІС інших суб’єктів,
а елемент yd при 2=y – про отримання
ВІС ia -го суб’єкта інформаційних ресур-
сів з ВІС інших суб’єктів. Таким чином, ці
елементи, так би мовити, визначають на-
прямок процесу обміну інформаційним ре-
сурсом в ІМІТС.
Множина суб’єктів А визначається
керівними органами на стадії замовлення
ДЦП та може уточнюватись на стадії роз-
роблення концепції ДЦП.
Множина інформаційних ресурсів
В, що підлягають обміну в ІМІТС, визна-
чаються сукупними потребами кожного
суб’єкта ІМІТС з урахуванням переліку
інформаційних ресурсів як для відправ-
лення, так і для отримання на стадії обсте-
ження відповідних суб’єктів.
Множина технологій обміну інфор-
маційними ресурсами, як вже було описа-
но, визначається технологіями:
- 1c – повідомлення;
- 2c – запит/відповідь ( ac2 – запит,
bc 2 – відповідь на запит).
Перетин вектора D з цими множи-
нами утворюють пари векторів, елементи
яких належать відповідним множинам.
Так, перетин вектора D з множиною
А утворює пару векторів: вектор відправ-
ників інформаційних ресурсів
'
1
'' }{ I
iiaA ==
та вектор отримувачів цих ресурсів
''
1
'''' }{ J
jjaA == . Переліки елементів цих век-
торів можуть не збігатися між собою, якщо
якийсь з суб’єктів тільки отримує інфор-
маційні ресурси не відправляючи їх іншим
суб’єктам. Більше того, перелік елементів
векторів може не збігатися з елементами
множини А, якщо якийсь з суб’єктів ІМІТС
не приймає участі в обміні інформаційни-
ми ресурсами, а тільки забезпечує цей об-
мін, наприклад, за допомогою СТМ.
Перетин вектора D з множинами А
та В утворює для кожного елемента ia
множини А (тобто, для кожного суб’єкта)
відповідні пари векторів: вектор інформа-
ційних ресурсів
'
1
'' }{ Y
yyii bB == ВІС ia -го
суб’єкта, призначених для передачі у ВІС
інших суб’єктів ІМІТС, та вектор інфор-
маційних ресурсів
''
1
'''' }{ Y
yyii bB == , які необ-
хідно отримувати ВІС ia -го суб’єкта від
ВІС інших суб’єктів ІМІТС. Вектори 'B та
''B відрізняються від множини В, крім
призначення, переліку елементів ще й фо-
рмою інформаційного ресурсу (транспорт-
ний файл) та наявністю ЕЦП. Таким чи-
ном, таких пар векторів буде стільки
скільки суб’єктів ІМІТС приймає участь у
процесі обміну інформаційними ресурса-
ми.
Перетин вектора D з множиною С
утворює пару векторів: вектор технологій
'C відправлення інформаційних ресурсів
та вектор технологій ''C – їх отримання.
При обміні інформаційними ресур-
сами за технологією 1c необхідні програ-
мно-апаратні засоби для забезпечення ре-
жимів:
'
1c – відправлення інформаційного
ресурсу: формування транспортного фай-
лу-повідомлення з даних ВІС-відправ-
ника, “накладання” електронно-цифрового
підпису, експорт означеного електронного
документа до абонентського пункту СТМ
[5];
''
1c – отримання інформаційного ре-
сурсу: імпорт електронного документа від
абонентського пункту СТМ, “зняття” елек-
тронно-цифрового підпису, передача
Електронний уряд
58
отриманого файлу-повідомлення до ВІС
отримувача [5].
При обміні інформаційними ресур-
сами за технологією 2c необхідні програм-
но-апаратні засоби для забезпечення ре-
жимів:
'
2ac – відправлення інформаційного
ресурсу: формування транспортного фай-
лу-запиту відправника, “накладання” елек-
тронно-цифрового підпису, експорт озна-
ченого електронного документа до абоне-
нтського пункту СТМ;
''
2ac – отримання інформаційного
ресурсу: імпорт електронного документа
від абонентського пункту СТМ, “зняття”
електронно-цифрового підпису, передача
отриманого файлу-запиту до ВІС отриму-
вача.
'
2bc – відправлення інформаційного
ресурсу: формування транспортного фай-
лу-відповіді суб'єкта-відправника, “накла-
дання” електронно-цифрового підпису,
експорт означеного електронного докуме-
нта до абонентського пункту СТМ;
''
2bc – отримання інформаційного
ресурсу: імпорт електронного документа
від абонентського пункту СТМ, “зняття”
електронно-цифрового підпису, передача
отриманого файлу-відповіді до ВІС отри-
мувача.
Перетин вектора D з множинами А,
В, С ув'язує утворені пари векторів 'B та
''B з технологіями інформаційного обміну.
Такий перетин, вірніше – елемент такого
перетину для yd при 1=y , наприклад, для
ВІС '
ia -го суб’єкта-відправника може бути
заданий структурою “один до кількох”:
відправник ( '
ia ) – отримувачі ( ''A ). Така
структура для довільного інформаційного
ресурсу zb з переліку інформаційних ре-
сурсів відправника, призначених для від-
правлення іншим суб'єктам, що враховує і
технологію інформаційного обміну, може
бути представлена у вигляді табл. 1.
Елемент такого перетину yd при
2=y для ВІС ''
ia -го отримувача може бути
заданий структурою “кілька до одного”:
відправники ( 'A ) – отримувач ( ''
ia ). Така
структура для довільного інформаційного
ресурсу jb з переліку інформаційних ре-
сурсів суб'єкта-отримувача, призначених
для отримання від інших суб'єктів, що вра-
ховує і технологію інформаційного обміну,
може бути представлена у вигляді табл. 2.
Таблиця 1. Елемент перетину множин А, В, С, та D щодо відправника
Технології обміну інформа-
ційними ресурсами
Інформаційні ресурси ВІС
'
ia -го відправника
Отримувачі ''A інформацій-
ного ресурсу
1c 2c 3c
''
1a + – –
''
2a – + –
… … … …
''
ia – – –
… … … …
''
ja + + –
… … … …
zb
''
Ja – + +
Електронний уряд
59
Таблиця 2. Елемент перетину множин А, В, С, та D щодо отримувача
Технології обміну інформа-
ційними ресурсами
Інформаційні ресурси ВІС
''
ja -го отримувача
Відправники 'A інформацій-
ного ресурсу
1c 2c 3c
'
1a +
– –
'
2a – + –
… … … …
'
ia + + –
… … … …
'
ja – – –
… … … …
zb
'
Ia – + +
Структури, що наведені в табл. 1 та
2, описують тільки процес передавання та
отримання інформаційних ресурсів і мо-
жуть лягти в основу побудови таблиць для
передпроектного обстеження потенційних
суб’єктів ІМІТС. Зрозуміло, що такі таб-
лиці матимуть інформаційну надлишко-
вість, тому що для визначення переліку
інформаційних ресурсів, призначених для
обміну між суб'єктами системи, цілком до-
статньо однієї з цих двох запропонованих
структур. Але така надлишковість має і
свої переваги: вона допоможе уникнути
помилок при зборі інформації про суб'єкти
ІМІТС під час їхнього обстеження. Дані
таких таблиць дозволять визначити кіль-
кість та перелік інформаційних ресурсів,
призначених для обміну у створюваній
ІМІТС та перелік програмно-апаратних
засобів, що забезпечать суб'єктам ІМІТС
відправлення та отримання визначених ре-
сурсів у відповідності до визначених тех-
нологій.
Ці дані у співставленні їх з аналогі-
чними даними системи-прототипу є осно-
вним фактором при визначенні відносної
трудомісткості розробки програмних засо-
бів, вираховуючи їх у обсягах коду, тобто
у кількості командних рядків.
4. Визначення прототипу ІМІТС
Для визначення прототипу ІМІТС
доцільно застосувати положення методу
аналогій, тобто розглядати процес вибору
аналога як послідовність декількох кроків:
1) вибір проектів-аналогів шляхом
аналізу завершених проектів, що мають
подібні характеристики (функціональне
завдання, функції, інформаційні техноло-
гії, процеси, процедури, операції, середо-
вище функціонування та ін.) на базі експе-
ртних оцінок;
2) оцінювання схожості та відмін
визначається на базі характеристик проек-
ту, що представляються у вигляді n-
вимірного евклідового простору, в якому
кожна характеристика – це окремий вимір,
тому найбільш схожі за характеристиками
проекти будуть мати меншу відстань у
просторі;
3) оцінювання якості вибраних ана-
логів проводиться з використанням мет-
рик: абсолютна помилка передбачення,
відносна помилка, відхилення відносної
помилки, середнє відхилення відносної
помилки, якість передбачення;
4) перегляд окремих ситуацій може
здійснюватись у тому випадку, коли про-
ект-аналог має характеристики, які необ-
хідно виключити з перегляду;
5) оцінювання – узагальнення
окремих оцінок та пошук найбільш прий-
нятних.
Хоча процес вибору аналога може
бути здійснено за допомогою програмного
інструментарію, наприклад, SPR
KnowledgePLAN або ANGEL (ANaloGy
Електронний уряд
60
softwarE tooL), де реалізовано математич-
ний метод оцінювання за аналогією, про-
цес оцінювання складається з тих же кро-
ків, але оцінювання здійснюється програм-
ними засобами з залучанням відповідних
даних з бази даних цього інструмента [19],
автори схиляються до застосування методу
експертних оцінок.
Використовуючи цей метод, у якос-
ті прототипу в межах технологій "повідом-
лення" та "запит-відповідь" була вибрана
система "Аркан", яка знаходиться на стадії
впровадження у дослідну експлуатацію.
Автори роботи є учасниками розробки си-
стеми "Аркан", тому їм досконально відомі
характеристики цієї системи, що дозволяє
у повній мірі оцінити трудомісткість її
розробки та співставити з трудомісткістю
розробки запроектованої ІМІТС.
У табл. 3 наведено результати спі-
вставлення прогнозованих функцій ІМІТС
та функцій прототипів "Аркан" у межах
задіяних технологій, технологічних проце-
сів, технологічних процедур у складі тех-
нологічних операцій.
Таблиця 3. Співсталення функцій ІМІТС та систем-прототипів
Функції ІМІТС – технологічні складові
Технологічні процедури у складових Технологічні процес
ВІС(і) ВП(і) ЦП ВП(j) ВІС(j)
Техно-
логія тип Пересилання ... ІМІТС прото-
тип
ІМІТС прото-
тип
ІМІТС прото-
тип
ІМІТС прото-
тип
ІМІТС прото-
тип
ТФ-повідомлення "A" Аркан "b" Аркан "a" Аркан "c" Аркан "B" Аркан
"А1"
ТФ-квитанції "D" Аркан "c" Аркан "a" Аркан "b" Аркан "C" Аркан
ТФ-повідомлення - - "d" Аркан "a" Аркан "c" Аркан "B" Аркан
Пові-
дом-
лення
"В1"
ТФ-квитанції - - "g" Аркан "a" Аркан "b" Аркан "C" Аркан
ТФ-запиту "E" Аркан "b" Аркан "a" Аркан "c" Аркан "F" Аркан
ТФ-відповіді "H" Аркан "c" Аркан "a" Аркан "b" Аркан "G" Аркан
"А2"
ТФ-квитанції "I" Аркан "b" Аркан "a" Аркан "c" Аркан "J" Аркан
ТФ-запиту - - "d" Аркан "a" Аркан "c" Аркан "F" Аркан
ТФ-відповіді - - "e" Аркан "a" Аркан "b" Аркан "G" Аркан
Запит-
відпо-
відь
"В2"
ТФ-квитанції - - "f" Аркан "a" Аркан "c" Аркан "J" Аркан
5. Структурна декомпозиція робіт
та відносний розподіл потреб
(витрат) ресурсів
Одним з популярних експертних
методів, який використовує поділ пробле-
ми на складові частини, вважається метод
декомпозиції робіт WBS (Work Breakdown
Structure). Він добре сполучається з мето-
дом Delphi для визначення складу робіт
проекту та їхньої оцінки [19].
Існують різні варіанти застосування
цього метода. Згідно одного з них, струк-
турна декомпозиція робіт проекту включає
дві складові: ієрархічну структуру робіт із
створення програмних систем та множину
підтримуючих дій, що необхідні для її реа-
лізації (наприклад, керування проектом,
забезпечення якості та ін.). На етапі визна-
чення потреб у ресурсах та їх витрат мно-
жину підтримуючих дій можна розглядати
як одну з характеристик ієрархічної струк-
тури робіт. До кожного елемента такої іє-
рархії слід прив’язати вартісні характерис-
тики (працевитрати, тривалість та вартість)
як прогнозні, так і фактичні.
В основі такої структурної деком-
позиції робіт із створення ІМІТС лежать
положення міждержавного стандарту [20]
та накопичений досвід створення подібних
систем, зокрема, системи-прототипу.
У загальному вигляді всі складові
компоненти виконання ДЦП із створення
ІМІТС можна представити як почергово
вкладені множини, що складаються з зав-
Електронний уряд
61
дань, заходів, комплексних робіт та окре-
мих робіт, причому кожному елементу
множини завдань виконання ДЦП можна
поставити у відповідність множину захо-
дів, за допомогою яких ці завдання можуть
бути виконані. Кожний захід може бути
представлений множиною комплексних
робіт, а кожна з них – множиною окремих
робіт.
Таким чином, для виконання прог-
рами необхідно zk завдань, що складають
множину PZ , де
}...,,...,,,{ 21
zkz
P ZZZZZ = ;
для виконання завдання zZ необхідно mk
заходів, що складають множину zM , де
}...,,...,,,{ 21
mzkzmzzz MMMMM = ;
для виконання заходу zmM необхідно rk
комплексних робіт, що складають множи-
ну zmR , де
}...,,...,,,{ 21
rzmkzmrzmzmzm RRRRR = ;
для виконання комплексної роботи zmrR
необхідно pk окремих робіт, що складають
множину zmrP , де
}...,,...,,,{ 21
pzmrkzmrpzmrzmrzmr PPPPP = .
Така декомпозиція завдань необ-
хідна для більш точного підраховування
трудомісткості всіх складових компонен-
тів, а вона визначається на самому ниж-
ньому рівні цих складових, тобто на рівні
окремих робіт.
Підраховування трудомісткості
окремих робіт zmrpP доцільно вести у від-
носних одиницях – коефіцієнтах трудоміс-
ткості робіт Т
zmrpK , щоб їх сума дорівнюва-
ла 1 у межах комплексної роботи zmrR , до
якої окремі роботи причетні. Той же підхід
і при підраховуванні коефіцієнтів трудомі-
сткості комплексних робіт Т
zmrK у межах
заходу zmM , до якого ці комплексні роботи
належать. І так далі – при підраховуванні
коефіцієнтів трудомісткості заходів Т
zmK у
межах завдання zZ , до якого ці заходи
відносяться, та при підраховуванні коефі-
цієнтів трудомісткості завдань Т
zK у ме-
жах всієї ДЦП, тобто:
1=∑
p
Т
zmrpK при 10 ≤≥ Т
zmrpK ,
1=∑
r
Т
zmrK при 10 ≤≥ Т
zmrK ,
1=∑
m
Т
zmK при 10 ≤≥ Т
zmK ,
1=∑
z
Т
zK при 10 ≤≥ Т
zK .
В табл. 4 наведено приклад можли-
вої декомпозиції комплексної роботи
5=zmrR заходу 3=zmM завдання 3=zZ ДЦП із
створення ІМІТС на окремі роботи zmrpP , де
}8...,,2,1{∈p , та трудомісткості їх вико-
нання T
zmrK 1= для тих же р. Декомпозиція
інших завдань, заходів та комплексних ро-
біт не наведена.
Добуток з відповідного набору кое-
фіцієнтів трудомісткості та загальної суми
коштів, що виділені на Програму, визна-
чать витрати на кожну складову Програми
на створення ІМІТС: окремі види робіт,
комплексні роботи або заходи.
Наведена в табл. 4 трудомісткість
визначається на основі досвіду та знань
витрат ресурсів на реалізацію відповідних
завдань при створенні системи-прототипу
та її технічних характеристик, зокрема що-
до розміру коду програмних засобів або
більш сучасному методу функціональних
точок (Function Points).
Дані щодо відносного розподілу по-
треб ресурсів при реалізації окремих ком-
понентів робіт при створенні різного типу
систем, зокрема, інформаційних (табл. 5),
можна взяти з літературних джерел, на-
приклад, [19].
Електронний уряд
62
Таблиця 4. Компоненти ДЦП та коефіцієнти трудомісткості їх виконання
Завдання, заходи, комплексні та окремі роботи
Формальний опис Коефіцієнти трудомісткості
зав-
дання
заходу комп-
лексної
роботи
окремої
роботи
Найменування окремої
роботи
комп-
лексної
роботи
заходу завдання
1=zZ Удосконалити нормативно-правове забезпечення функціонування системи T
zK 1=
2=zZ Виконати науково-дослідні роботи щодо методології створення та експлуатації системи T
zK 2=
Виконати роботи з проектування ІМІТС
1=zmM Обстеження об’єкта автоматизації та формування вимог користувача до ІМІТС T
zmK 1=
2=zmM Розроблення варіантів концепції ІМІТС з урахуванням прототипу T
zmK 2=
Розроблення технічного завдання на створення ІМІТС
1=zmrR Опис (короткі відомості) об’єкта автоматизації T
zmrK 1=
2=zmrR Відомості про умови експлуатації об’єкта автоматизації T
zmrK 2=
3=zmrR Розробка вимог до ІМІТС в цілому T
zmrK 3=
4=zmrR Розробка вимог до функцій (задач) ІМІТС T
zmrK 4=
Розробка вимог до видів забезпечення
1=zmrpP Розробка вимог до математичного забезпе-
чення
T
zmrpK 1=
2=zmrpP Розробка вимог до інформаційного забезпе-
чення
T
zmrpK 2=
3=zmrpP Розробка вимог до лінгвістичного забезпе-
чення
T
zmrpK 3=
4=zmrpP Розробка вимог до програмного забезпечен-
ня
T
zmrpK 4=
5=zmrpP Розробка вимог до технічного забезпечення T
zmrpK 5=
6=zmrpP Розробка вимог до метрологічного забезпе-
чення
T
zmrpK 6=
7=zmrpP Розробка вимог до організаційного забезпе-
чення
T
zmrpK 7=
5=zmrR
8=zmrpP Розробка вимог до методичного забезпечен-
ня
T
zmrpK 8=
T
zmrK 5=
6=zmrR Визначення складу та змісту робіт із створення ІМІТС T
zmrK 6=
7=zmrR Визначення порядку контролю та приймання ІМІТС T
zmrK 7=
3=zmM
8=zmrR Визначення вимог до складу і змісту робіт з підготовки об’єкта
автоматизації до вводу ІМІТС в дію
T
zmrK 8=
T
zmK 3=
4=zmM Розроблення ескізного проекту ІМІТС T
zmK 4=
3=zZ
5=zmM Розроблення технічного проекту ІМІТС T
zmK 5=
T
zK 3=
4=zZ Виконати роботи із розроблення ІМІТС T
zK 4=
5=zZ Виконати роботи з закупівлі технічного та загального програмного забезпечення ІМІТС T
zK 5=
6=zZ Впровадити ІМІТС в дослідну експлуатацію T
zK 6=
7=zZ Увести ІМІТС в промислову експлуатацію T
zK 7=
Електронний уряд
63
Таблиця 5. Дольовий розподіл витрат на створення інформаційних систем
Вид роботи
індекс найменування
Розподіл витрат (%)
1 Визначення вимог 7,5
2 Визначення прототипу для співставлення характеристик 2,0
3 Розробка архітектури 0,5
4 Планування проекту 1,0
5 Попереднє проектування 8,0
6 Технічне проектування 7,0
7 Програмування 20,0
8 Роботи з придбання пакетів загального ПЗ 1,0
9 Керування конфігурацією 3,0
10 Формальна інтеграція 2,0
11 Документація користувача 7,0
12 Автономне тестування 4,0
13 Функціональне тестування 6,0
14 Інтеграційне тестування 5,0
15 Системне тестування 7,0
16 Приймальне тестування 5,0
17 Інсталяція/навчання 2,0
18 Керування проектом 12,0
Всього 100,0
Такий підхід дає змогу визначити
трудомісткість, яка припадає на будь-який
компонент ДЦП. Якщо питомій трудоміст-
кості поставити у відповідність певний на-
бір необхідних ресурсів або суму коштів,
то можна визначити їхню необхідну кіль-
кість для реалізації будь-якого компонента
ДЦП та всієї ДЦП.
6. Визначення витрат на розробку
ІМІТС
Необхідні витрати на розробку
ІМІТС визначались за допомогою методів
математичного моделювання. Саме методи
математичного моделювання лягли в осно-
ву побудови відповідного програмного ін-
струментарію – математичної моделі СО-
СОМО для оцінки вартості та трудоміст-
кості розробки програмного забезпечення
(CОnstructive CОst MОdel), розробленої у
1981 р. за замовленням Міноборони США
спеціально для експертизи програмних
проектів. При побудові цієї моделі викори-
стовувався багатофакторний регресійний
аналіз.
Подальший розвиток цієї моделі –
COCOMO II – хоча і має багато спільного з
попередньою, однак на відміну від неї, яка
орієнтована на каскадну модель життєвого
циклу, вона придатна також для спіральної
[21] та ітеративної моделі. При побудові
цієї моделі використовувався Байєсовсь-
кий аналіз, який дає кращі результати для
програмних проектів, що характеризують-
ся неповнотою та неоднозначністю. У ній
допускається вимірювати розмір проекту
не тільки кількістю рядків коду, але і
більш сучасними функціональними та об'-
єктними точками [22].
Метод функціональних точок
(Function Points) ґрунтується на вивченні
вимог, що дозволяє виконати оцінку необ-
хідних трудовитрат на самих ранніх стаді-
ях роботи над проектом ІМІТС і в подаль-
шому уточнювати їх за ходом життєвого
циклу. Під функціональними точками у
термінах моделі СОСОМО розуміють ек-
ранні форми, звіти, таблиці в базі даних,
файли та повідомлення для обміну з інши-
ми програмами тощо, тобто реально вимі-
рювані показники (скільки та яких інфор-
Електронний уряд
64
маційних об'єктів та даних мають
оброблюватися у програмі [22].
Метод об'єктних точок адаптовано
до об'єктно-орієнтованого підходу у су-
часних проектах, що оперують саме термі-
нами об'єктно-орієнтованої технології.
COCOMO II має кілька варіантів за-
стосування, фактично це різні підмоделі
для вирішення різних (хоча і схожих) за-
дач, об'єднані загальною назвою [22].
Поза іншим, ця модель ураховує рі-
вень зрілості процесу розробки за такими
аспектами: показники процесу проекту-
вання, показники програмного проекту,
показники розробників, показники апарат-
них засобів у відповідності до засад моделі
СММ (Capability Maturity Model
for software), яка дозволяє визначити гото-
вність розробника виконувати програмні
проекти певного рівня. Вона ураховує сту-
пінь упровадження на підприємстві світо-
вих стандартів, процедур якості, техноло-
гій розробки та супроводження програм-
них проектів. Модель ця була розроблена
за замовленням Міноборони США саме
для таких випадків – перевірити, чи відпо-
відає кваліфікація розробника рівню, що
необхідний для виконання його замовлень.
У табл. 6 наведені дані однієї з таких мо-
делей [19].
Таблиця 6. Дані моделі СММІ для визначення рівня розробки
Категорія процесів Область процесів Рівень розробки
Інд. Найменування Інд. Найменування 1 2 3 4 5
1.1 Забезпечення процесного підходу в організації + + +
1.2 Визначення процесу на рівні організації + + +
1.3 Навчання в (на рівні) організації + + +
1.4 Виконання процесу в організації + +
1 Керування про-
цесом
1.5 Інновації та впровадження в організації +
2.1 Планування проекту + + + +
2.2 Моніторинг і контроль проекту + + + +
2.3 Керування постачальниками + + + +
2.4 Інтегроване керування проектом + + +
2.5 Керування ризиком + + +
2.6 Кількісне керування проектом + +
2 Керування прое-
ктом
2.7 Інтегроване навчання в проекті + + +
3.1 Керування вимогами + + + +
3.2 Розроблення вимог + + +
3.3 Технічні рішення + + +
3.4 Інтеграція продукту + + +
3.5 Верифікація + + +
3 Інженерія
3.6 Валідація + + +
4.1 Керування конфігурацією + + + +
4.2 Гарантія якості процесу та продукту + + + +
4.3 Вимірювання та аналіз + + +
4.4 Аналіз причин та вирішення проблем +
4.5 Аналіз і прийняття рішень + + +
4 Підтримка
4.6 Умови та середовище в організації для інтеграції + + +
Саме модель СОСОМО ІІ викорис-
товувалась для визначення необхідних ви-
трат на розробку ІМІТС. За її допомогою,
виходячи з прогнозного обсягу коду необ-
хідних програмних засобів ІМІТС, серед-
ніх заробітних плат персоналу та наклад-
них витрат при розробці, були визначені
трудомісткість розробки, кількість необ-
хідного персоналу розробників та загальна
вартість розробки. Використовуючи дані
табл. 4 та 5, можна розрахувати вартість за
окремими позиціями ДЦП.
Електронний уряд
65
Висновки
Відомо, що найбільш дієвим шля-
хом до побудови міжвідомчих інформа-
ційних систем є державні цільові програ-
ми, які об'єднують зусилля відомств у цих
напрямках як у цільовому, так і в матеріа-
льному аспекті. Відомо також, наскільки
важливо при створенні таких ДЦП визна-
чити найбільш реальні обсяги коштів, не-
обхідних для їх реалізації. Один із шляхів
прогнозування обсягів необхідних коштів
для створення ІМІТС у межах подібних
ДЦП запропоновано у цій роботі.
На різних етапах цього шляху ши-
роко застосовуються окремі положення
методів експертних оцінок, аналогій та ма-
тематичного моделювання найбільш для
цього придатних за своїми показниками,
про що наголошувалось у роботі. На етапі
визначення функцій такої системи викори-
стовувалися експертні знання щодо деталі-
зації проектних рішень у цьому напрямку
аж до окремих технологічних процесів,
процедур та операцій, що дозволило, за-
стосовуючи метод аналогій, визначити си-
стему-прототип з її функціональними мо-
жливостями. Визначення трудомісткості
створення ІМІТС, необхідного за кількістю
колективу розробників, терміну розробки
та необхідних для реалізації проекту кош-
тів відбувалось за допомогою відповідного
програмного інструментарію – моделі СО-
СОМО ІІ.
1. Постанова Кабінету Міністрів України від
24.02.2003, № 208 "Про заходи щодо ство-
рення електронної інформаційної системи
"Електронний Уряд"".
2. Алексеєв В.А., Ільїн С.А., Мягкова Л.А., Те-
рещенко В.С. Організація схем взаємодії
в інтегрованій міжвідомчій інформаційній
системі // Проблемы программирования. –
2003. – № 3. – С. 71–83.
3. Алексеєв В.А., Терещенко В.С. Архітектура
інтегрованої міжвідомчої інформаційної
системи як композиція відомчих інформа-
ційних систем / Матеріали IV міжнар.
наук.-практ. конф. з програмування (Укр-
ПРОГ’2004) 1–3 червня 2004 // Проблемы
программирования”. – 2004. – № 2-3. –
С. 397–408.
4. Алексеєв В.А., Мягкова Л.А., Терещенко
В.С. Синтез схеми архітектури міжвідом-
чої інформаційної системи на основі ана-
лізу функцій її компонентів // Управляю-
щие системы и машины. – 2004. – № 5. –
С. 11–24.
5. Алексеєв В.А., Ільїн С.А., Терещенко В.С.
Моделювання процесів обміну інформа-
цією в інтегрованій міжвідомчій інфор-
маційній системі / Матеріали V міжнар.
наук.-практ. конф. з програмування (Укр-
ПРОГ’2006) 23–25 травня 2006 // Пробле-
ми програмування. – 2006. – № 2-3. –
С. 548–559.
6. ДСТУ 2227-93. Системи оброблення інфор-
мації. Автоматизована установа. Терміни
та визначення. Держстандарт України.
7. Закон України вiд 22.05.2003, № 851-IV
"Про електронні документи та електро-
нний документообіг".
8. Закон України від 02.10.1992, № 2657-XII
“Про інформацію”.
9. Закон України від 31.05.05 № 2594-IV – ВР
„Про захист інформації в ІТС”.
10. НД ТЗІ 3.7-003-2005. "Порядок проведення
робіт із створення комплексної системи за-
хисту інформації в інформаційно-
телекомунікаційній системі". ДСТСЗІ СБ
України.
11. НД ТЗІ 2.5-004-1999. "Критерії оцінки за-
хищеності інформації в комп’ютерних сис-
темах від несанкціонованого доступу".
ДСТСЗІ СБ України.
12. Постанова Кабінету Міністрів України від
29.01.2003, № 140 "Про затвердження Про-
грами протидії легалізації (відмиванню)
доходів, одержаних злочинним шляхом, на
2003 рік".
13. Постанова Кабінету Міністрів України від
10.12.2003, № 1896 "Про Єдину державну
інформаційну систему у сфері запобігання
та протидії легалізації (відмиванню) дохо-
дів, одержаних злочинним шляхом, і фі-
нансуванню тероризму".
14. Розпорядження Кабінету Міністрів Украї-
ни від 19.04.2006, № 215-р "Про затвер-
дження плану заходів із створення інтегро-
ваної міжвідомчої інформаційно-
телекомунікаційної системи щодо контро-
лю осіб, транспортних засобів та вантажів,
які перетинають державний кордон, до
2008 року".
15. Розпорядження Кабінету Міністрів
України від 19.09.2007 р. № 754-р "Про
схвалення Концепції Державної програми
інформаційно-телекомунікаційного забез-
печення правоохоронних органів,
Електронний уряд
66
діяльність яких пов’язана з боротьбою із
злочинністю".
16. Єдина державна інформаційна система у
сфері запобігання та протидії легалізації
(відмиванню) доходів, одержаних злочин-
ним шляхом, і фінансуванню тероризму
(ЄІС ФМ). Технічне завдання.
20024089.088-ТЗ.
17. Положення про міжвідомчу інформаційно-
телекомунікаційну систему щодо контро-
лю осіб, транспортних засобів та вантажів,
які перетинають державний кордон.
Наказ від 03.04.2008,
№ 284/287/214/150/64/175/266/75. Зареєст-
ровано в Міністерстві юстиції України
12.05.2008, № 396/15087.
18. Інтегрована міжвідомча інформаційно-
телекомунікаційна система щодо контролю
осіб, транспортних засобів та вантажів, які
перетинають державний кордон України
(система "Аркан"). Технічне завдання. – К.:
ІПС, 2005. – 15 с.
19. Андон Ф.И., Лаврищева Е.М., Суслов В.Ю.
и др. Основы инженерии качества програм-
мных систем. – 2-е изд., перераб. и доп. –
К.: Академпериодика, 2007. – 672 с.
20. ГОСТ 34.601-90 Информационная техно-
логия. Комплекс стандартов на автомати-
зированные системы. Автоматизированные
системы. Стадии создания.
21. Алексеєв В.А., Терещенко В.С. Розвиток
спіральної моделі життєвого циклу про-
грамної системи // Проблемы программи-
рования. – 2003. – № 4. – С. 32–44.
22. Колдовский В. Разработка ПО: оценка ре-
зультата. http://itc.ua/node/25631.
Отримано 05.12.2008
Про авторів:
Алексеєв Віктор Анатолійович,
кандидат технічних наук, завідуючий
відділом,
Терещенко Валерій Савелійович,
кандидат технічних наук, старший
науковий співробітник.
Місце роботи авторів:
Інститут програмних систем НАН України.
Тел.: (044) 526 4228; 526 6191.
|