Менеджмент проекту інформаційної системи ПІдтримки нормативно-правового забезпечення органів державного управління
Аналізується менеджмент проекту інформаційних систем (ІС) управлінської діяльності на базі сучасних принципів керування ство-
 ренням програмного забезпечення. Визначена формальна модель проектного менеджменту таких систем. Наведено приклад застосування
 запропонованих принципів The...
Збережено в:
| Дата: | 2004 |
|---|---|
| Автор: | |
| Формат: | Стаття |
| Мова: | Українська |
| Опубліковано: |
Інститут програмних систем НАН України
2004
|
| Теми: | |
| Онлайн доступ: | https://nasplib.isofts.kiev.ua/handle/123456789/2275 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Цитувати: | Менеджмент проекту інформаційної системи ПІдтримки нормативно-правового забезпечення органів державного управління /Н.Т.Задорожна // Проблеми програмування. — 2004. — N 2,3. — С. 155-162. — Бібліогр.: 6 назв. — укр. |
Репозитарії
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1860265532345810944 |
|---|---|
| author | Задорожна, Н.Т. |
| author_facet | Задорожна, Н.Т. |
| citation_txt | Менеджмент проекту інформаційної системи ПІдтримки нормативно-правового забезпечення органів державного управління /Н.Т.Задорожна // Проблеми програмування. — 2004. — N 2,3. — С. 155-162. — Бібліогр.: 6 назв. — укр. |
| collection | DSpace DC |
| description | Аналізується менеджмент проекту інформаційних систем (ІС) управлінської діяльності на базі сучасних принципів керування ство-
ренням програмного забезпечення. Визначена формальна модель проектного менеджменту таких систем. Наведено приклад застосування
запропонованих принципів
The information systems project management process to support for Government bodies is analyzed. The analyses is based on modern principles
of software management project. The formal model for project management of information systems in this area is defined.
The example using of the proposed principles is represented.
|
| first_indexed | 2025-12-07T19:00:20Z |
| format | Article |
| fulltext |
1
МЕНЕДЖМЕНТ ПРОЕКТУ ІНФОРМАЦІЙНОЇ СИСТЕМИ ПІДТРИМКИ
НОРМАТИВНО-ПРАВОВОГО ЗАБЕЗПЕЧЕННЯ ОРГАНІВ
ДЕРЖАВНОГО УПРАВЛІННЯ
Задорожна Н. Т.
Інститут засобів навчання АПН України, 04060, м.Київ, вул.. М.Берлинського, 9, 440-213-8286
admin@edu-ua.net
Аналізується менеджмент проекту інформаційних систем (ІС) управлінської діяльності на базі сучасних принципів керування ство-
ренням програмного забезпечення. Визначена формальна модель проектного менеджменту таких систем. Наведено приклад застосування
запропонованих принципів
The information systems project management process to support for Government bodies is analyzed. The analyses is based on modern prin-
ciples of software management project. The formal model for project management of information systems in this area is defined.
The example using of the proposed principles is represented.
Вступ
Головне завдання ІС підтримки діяльності органів державного управління полягає у створенні інформацій-
ного середовища на базі мережевих, комп'ютерних, програмно-технічних засобів та сучасних технологій для за-
безпечення ефективних процесів управління та прийняття рішень в умовах активного розвитку суспільства та
проведення адміністративної реформи управління. Завдання ІС цього класу полягає у здійсненні інформаційно-
аналітичної підтримки процесів управління і забезпеченням управлінського апарату достовірною, повною, опера-
тивною інформацією, оскільки саме це є необхідною умовою прийняття обґрунтованих рішень і чинником біль-
шої дієвості, гнучкості, динамічності в діяльності управлінських органів.
На теперішній час існує широкий спектр програмних систем, які вирішують задачі електронної обробки
документів в тому числі в органах державного управління. Однак створення цілісної cистеми з врахуванням бага-
тьох конкретних факторів цієї предметної області потребує технології проектування з визначенням принципів,
методик та моделей, на базі яких можна виконувати розробку власної програмної системи або здійснювати нау-
ково обґрунтований вибір відповідних програмних платформ, які пропонує сучасний ринок.
Разом з тим, успішність розробки значною мірою залежить від менеджменту проекту ІС. Методи та засоби
проектного менеджменту (Project Management) застосовуються для різних предметних областей, у тому числі і
при проектування ІС. Метою менеджменту проекту ІС є визначення критеріїв вибору та прийняття оптимальних
рішень на всіх етапах її ЖЦ. Під менеджментом проекту ІС розуміється планування, управління ризиками та об-
сягом проекту, управління часовими витратами, управління вартістю.
Менеджмент проекту (МП) ґрунтується на використанні визначених знань, умінь, засобів та методів для
досягнення поставленої мети. Досвід реалізації навіть відносно нескладних проектів свідчить, що труднощі, з
якими стикаються розробники, обумовлені браком знань по сучасних методах та засобах ведення проекту, відсу-
тності методології створення ІС, а також невмінням організувати ефективну проектну команду.
Ефективне застосування методик МП дозволяє здійснювати практичне керування програмними проекта-
ми у умовах обмеженого часу та ресурсів, використовувати кращі практичні рішення щодо планування та контро-
лю (бачення продукту, стартові операції, планування ітерацій, моніторинг, звітність), планувати та керувати ризи-
ками, оптимально організовувати командну роботу та комунікаційні потоки у команді розробників, як внутрішні,
так і зовнішні. Вже існує цілий клас програмних продуктів по керуванню та контролю проектами, що забезпечує
технологічну підтримку впровадження методик МП в практику розробки ІС. Тому важливим і актуальним за-
вданням є розвиток і запровадження методологічних основ керування проектуванням ІС управлінської діяльності
на базі сучасних принципів керування створенням програмного забезпечення Це завдання були предметом теоре-
тичного дослідження та практичного застосування при проектуванні конкретною ІС, а саме, автоматизованого
банку даних “Cистема нормативно-правового і методичного забезпечення організації навчального процесу в за-
гальноосвітніх закладах України на базі мережі Інтернет” (ДР 0101U006513), далі ІС “ЗНЗ”. Автор виконував
обов’язки менеджеру цього проекту.
В межах проведеного дослідження проведено аналіз сучасних принципів МП і технологій його підтримки,
визначено формальну моделі керування проектуванням, яка враховує матеріальні та трудові ресурси, необхідні
для виконання розробки ІС, проведена апробація моделей та концепцій методів керування проектуванням цієї
ІС. Головні результати стосовно МП, отримані в результаті проведеного дослідження, описані в статті.
В процесі виконання проекту дуже важливо було забезпечити МП щодо економічних питань, тому спочат-
ку доцільно представити окремі сучасні оцінки і методики, теоретичні положення і застосування яких сприяло
успішній реалізації проекту. Розпорядженням МОН України система ІС “ЗНЗ” введена в дію в 2003 році із реєст-
2
рацією в мережі Інтернет за адресою www.znz.edu-ua.net. За рік експлуатації зареєстровано понад 100 організацій-
користувачів, щоденно сайт відвідує біля 50 користувачів.
1. Економічні аспекти менеджменту проекту ІС
Під ІС розуміється організаційно упорядкована сукупність документів, інформаційних технологій та засо-
бів обчислювальної техніки і зв’язку, що реалізують інформаційні процеси. Інформаційні технології (ІТ) можна
визначити як систему методів та способів збору, передачі, накопичення, обробки, зберігання, представлення та
використання інформації на основі застосування технічних засобів [1]. Таким чином, створення ІС значною мі-
рою полягає у розробці відповідного програмного забезпечення (ПЗ), що реалізує і підтримує зазначені процеси у
відповідності з її функціональними задачами. Тому проблему менеджменту проекту ІС будемо розглядати у кон-
тексті керування розробкою ПЗ (Software Project Management).
Індустрія ПЗ рухається в бік нових методів керування проектами все зростаючої складності. В той час, ко-
ли технології програмування, процеси та методи швидко розвиваються, розробка ПЗ залишається процесом з ін-
тенсивним використанням людської праці. Отже, способи управління людьми, технологією, ресурсами та ризика-
ми мають великий запас потенціальних можливостей[2]. Менеджмент проектування ПЗ останнім часом розгляда-
ється в ракурсі, при якому особлива увага приділяється балансу між такими елементами:
� Теорія і практика
� Технологія і люди
� Вартість для замовника та прибутковість для виробника
� Стратегія і тактика
Найважливішим аспектом керування є поняття балансу. Необхідно забезпечити баланс між цілями зацікав-
лених сторін, які спілкуються між собою за допомогою різних мов і систем позначень.
Розробці ПЗ притаманні три фундаментальні мови представлення: вимог (мова проблемної області), проек-
тні рішення (мови трансформації, які використовують розробники ПЗ і реалізації (мова, що розуміється
комп’ютером). Методи керування розробкою ПЗ дозволяють перевести існуючу проблему у рішення так, щоб
задовольнити усі зацікавлені сторони. При цьому МП з одного боку є сукупністю науки, реалізму та досвіду у
вигляді рішень, інструментів, технологій, а з іншого предметом міркувань, здорового глузду у прийнятті рішень в
залежності від ситуації.
1.1. Еволюція економіки розробки ПЗ. Програмна інженерія великою мірою являє собою інтелектуаль-
ний вид діяльності, направлений на рішення проблем найвищого рівня з безкінечним числом невідомих в умовах
постійних змін. Підходи щодо створення ПЗ 60-х і 70-х рр. краще описувати терміном “кустарне виробництво”,
коли в у кожному проекті використовувався власний процес і власний інструментарій. У 80-х та 90-х рр. індустрія
створення ПЗ перейшла до розряду інженерної дисципліни. Проте більшість проектів по створенню ПЗ цього пе-
ріоду передбачало проведення інтенсивних досліджень, яким були притаманні творчій підхід та плата за масштаб.
Сучасне покоління процесів створення ПЗ рухається в бік підходу з інтенсивнішим виробництвом, якому власти-
ві автоматизація та економія при великих масштабах.
1.1. 1. Економіка ПЗ. Більшість моделей для визначення вартості ПЗ зведено до функції п’яти головних
параметрів: розміру, процесу, персоналу, середовища та потрібної якості.
1. Розмір кінцевого продукту (для компонентів, написаних вручну), який звичайно вимірюється числом ря-
дків вихідного коду або кількістю функціональних точок, необхідних для реалізації визначеної функціо-
нальності.
2. Особливості процесу, який використовується для отримання кінцевого продукту, зокрема його здатність
уникати невиробничих видів діяльності (переробок, бюрократичних затримок, витрат на взаємодію).
3. Можливості персоналу, який бере участь в розробці ПЗ, особливо його професійний досвід та знання
предметної області проекту.
4. Середовище, що складається із інструментів та методів, які використовуються для ефективної розробки
ПЗ та автоматизації процесу.
5. Потрібна якість, що включає його функціональні можливості, продуктивність, надійність та адаптова-
ність.
Співвідношення між розрахованою вартістю та цими параметрами можна записати так [2]:
Трудомісткість = (Персонал) (Середовище)(Якість) (РозмірПроцес)
Для оцінки вартості ПЗ створено декілька параметричних моделей. Всі вони можуть бути зведені до пода-
ної вище форми. Один із важливих аспектів економіки створення ПЗ (як це представляється у сучасних моделях
визначення вартості ПЗ) полягає в тому, що зв’язок між роботою та розмірами визначає плату за великий масш-
таб. Плата за великий масштаб про розробці ПЗ є результатом того, що показник експоненти процесу більше
одиниці. На відміну від більшості виробничих процесів, чим більше ПЗ створюється, тим воно дорожче, якщо
перерахувати на одну одиницю. Наприклад, для деякого довільного застосування програмне рішення обсягом у
10000 рядків буде дешевше при розрахунку на один рядок, ніж програмне рішення обсягом у 100000 рядків. На
скільки дешевше? Припустимо, що для створення 100000-рядкової системи потрібно 900 людино-місяців, або
близько 111 рядків за один людино-місяць, або 1б37 години на один рядок. Якби таж сама система складалася із
10000 рядків при незмінних інших параметрах, то проект би оцінювався б приблизно у 62 людино-місяці, або 175
3
рядків за один людино-місяць, або 0.87 години на один рядок. Вартість одного рядка для меншого застосування
виявляється значно нижчою, ніж для більшого застосування. Причина цього полягає передусім у складності ке-
рування міжособистосними ми взаємодіями із зростанням кількості членів команди (и відповідно кількості цілей,
умов їх досягнення, технічних переваг). Ця плата за великий масштаб характерна для будь-якого дослідницького
проекту, продуктом якого унікальний об’єкт інтелектуальної власності.
1.1.2. Покоління технології МП. В табл.1 представлені три покоління головних досягнень технологій МП
щодо інструментарію, компонентів, процесів. Необхідний рівень якості і персонал приймаються постійними.
Таблиця 1.
Три покоління головних досягнень технологій: інструментарій, компоненти, процеси
Загальна характеристика
− 60-і – 70-і рр.
− Водоспадна модель
− Функціональне проектування
− Плата за масштаб
− 80-і – 90-і рр.
− Удосконалення процесу
− Підхід, побудований на
інкапсуляції
− Плата за масштаб
− Починаючи х 2000р.
− Ітераційна розробка
− Компонентно-орієнтований підхід
− Повернення інвестицій
Середовище, розмір та технології процесів
Середовище/інструментарій
Кустарне
Розмір:
100% на замовлення
Процесс:
Вузькоспеціалізований
Середовище/інструментарій
Готові, локальні
Розмір:
30% на базі готових компонент
70% на замовлення
Процесс:
Відтворюваний
Середовище/інструментарій
Інтегроване середовище автомати-
зації
Розмір:
70% на базі готових компонент
30% на замовлення
Процесс:
Керований/вимірюваний
Типова ефективність проекту
Передбачувано погана
Завжди:
Перевищення бюджету
Перевищення термінів
Непередбачувана
Рідко:
У межах бюджету
За графіком
Передбачувана
Звичайно
У межах бюджету
За графіком
Три покоління процесів розробки ПЗ визначимо таким чином:
1. Традиційний: 60-ї – 70-і рр., кустарне виробництво. Організації використовують кустарний інструмен-
тарій, кустарні процеси і практично усі компоненти для замовника пишуться на примітивних мовах.
Результат виконання проекту було легко передбачити в тому сенсі, що він практично ніколи вкладався в
наперед визначену вартість, терміни, та якість.
2. Перехідний: 80-і – 90-і рр., програмна інженерія. Організації використовують відтворювані процеси та
готові інструменти, а більшість створюваних компонент (>70%) пишуться на мовах високого рівня. Де-
які компоненти (<30%) стають доступні в якості комерційного продукту, включно з операційними сис-
темами, системами керування базами даними, мережевим ПЗ та графічним інтерфейсом користувача.
Протягом 80-х рр. Деякі організації починають досягати економі при великих масштабах, але із збіль-
шенням складності застосувань (особливо при переході на розподілені системи) існуючі мови, методи
та технології виявилися недостатніми для того, щоб підтримувати необхідний рівень промислового про-
ектування.
3. Сучасна практика: починаючи з 2000р., виробництво ПЗ. Передові організації широко застосовують
керовані та вимірювані процеси, інтегровані середовища автоматизації і більшу час тину (70%) готових
компонентів. Можливо, всього 30% компонентів належить строювати на замовлення. Використовуючи
переваги технології створення ПЗ та інтегрованих середовищ розробки, можна дуже швидко створю-
вати системи, побудовані на компонентах.
Технології, які дозволяють автоматизувати середовище розробки, зменшити розмір ПЗ та удосконалити
процес, не є незалежними. Для кожного періоду часу ключовим стає деяке удосконалення усіх технологій. На-
приклад, переваги нового процесу не можуть бути успішно використані без нових технологій створення компоне-
нтів та підвищення ступеню автоматизації.
1.2. Практична оцінка вартості ПЗ. Однією із важливих проблем при оцінці ПЗ є відсутність добре до-
кументованих практичних приладів проектів, де використовувалася ітераційна розробка. Серед розробників та
постачальників моделей та засобів для оцінки вартості ПЗ ідуть суперечки щодо:
1. Яку модель вартості ПЗ належить використовувати?
4
2. Вимірювання обсягу ПЗ належить виконувати в рядках вихідного коду або у функціональних точках?
3. Що може вважатися хорошою оцінкою?
В індустрії ПЗ між собою конкурують біля 50 постачальників засобів, даних та послуг для оцінки вартості
ПЗ. Відомі загальнодоступні моделі та засоби для оцінки вартості ПЗ.( такі як COCOMO, CHEKPOINT,
ESTIMACS, KnowledgePlan, Price-S, ProQMS, SEER, SLIM, SOFTCOST та SPQR/20), а також величезна кількість
моделей, які застосовуються в конкретних організаціях.
В питання вимірювання обсягу ПЗ домінують дві точки зору: рядки вихідного коду (SLOC) [3] або у функ-
ціональні точки.
Раніше SLOC як одиниці вимірювання добре працювали, оскільки вимірювання в рядках вихідного тексту
легко автоматизувати і здійснити на практиці. Сьогодні можливості сучасних мов та застосування компонентів,
автоматична генерація коду та орієнтація на об’єкти зробили SLOC неточною одиницею вимірювання. Вже іс-
нують ретельно пророблені підходи для підрахування SLOC, які забезпечують врахування повторне використан-
ня, розробку на замовлення та інструментарій для генерації коду в межах великих проектів по створенню ПЗ.
Застосування функціональних точок має багато послідовників, які вказують на складності, пов’язані з ви-
користанням SLOC для об’єктно-орієнтованих програм. Міжнародний консорціум по використанню функціона-
льних точок (the International Function Point User’s Group), утворений в 1984 р., є домінуючою асоціацією по пи-
таннях вимірювання ПЗ. Найголовнішою перевагою застосування функціональних точок є те, що цей метод не
залежить від конкретної технології , таким чином, надає елементарні одиниці вимірювання для порівняння різних
проектів та організацій. Головний його недоліком полягає в тому, що визначення абстрактні, а спосіб проведення
вимірювань не випливає безпосередньо з положень, які входять до нього. При порівняні різних проектів або різ-
них організацій належить використовувати функціональні точки. Вони є більш точним способом вимірювання на
ранніх стадіях ЖЦ проекту. На пізніх же стадіях кориснішою і точнішою основою для різних вимірювань стає
SLOC.
Із чого складається хороша оцінка вартості ПЗ? Вона повинна мати такі атрибути:
� Вона створюється і підтримується менеджером проекту, командою по розробці архітектури, командою
розробників і командою тестувальників, тобто усіма, хто відповідає за виконання робіт.
� Вона сприймається усіма виконавцями як амбіціозна, але така, що може бути виконана.
� Вона базується на докладно описаній моделі вартості ПЗ, що має основу, яка заслуговує довіру.
� Вона засновується на даних по аналогічних проектах, які включають аналогічні процеси, аналогічні
технології, аналогічне середовище, аналогічні вимоги до якості і аналогічну кваліфікацію робітників
� Вона докладно описується таким чином, щоб було добре видно усі ключові області ризику, і вірогід-
ність успіху оцінювалася об’єктивно.
Ідеальну оцінку можна знайти шляхом екстраполяції хорошої оцінки, отриманої на основі усталеної моде-
лі вартості з використанням досвіду виконання аналогічних проектів тою ж командою, яка застосовувала зрілі
процеси та інструментарій. Така ситуація на практиці зустрічається рідко. Коло команда починає здійснення но-
вого проекту, хороші оцінки можуть біти отримані звичайним шляхом на пізніших етапах ЖЦ зрілого проекту,
що використовує зрілий процес.
Далі розглянемо, як представлені в цьому розділі теоретичні положення та підходи МП щодо економічних
аспектів розробки ПЗ були використані в керуванні проектуванням ІС “ЗНЗ”.
2. Менеджмент проекту ІС “ЗНЗ”
2.1. Методи дослідження. Комплекс досліджень по технології проектування ІС “ЗНЗ” проводився із за-
стосуванням об’єктно-орієнтованого підходу до їх системного аналізу. Процес керування проектуванням ІС до-
сліджувався з використанням методів проектного менеджменту, зокрема методів “критичного шляху” (CPM–
Critical Path Method), схеми організації робіт PERT (Program Evaluation and Review Technique) та методів проек-
тування на основі спіральної моделі. При визначенні формальної моделі керування проектом використовувався
апарат теорії графів. Методика дослідження предметної області СУД розроблена з використанням теорії масового
обслуговування. Проектування ІС “ЗНЗ” з використанням підходів, моделей та методів, отриманих в результаті
проведених досліджень, базувалося на архітектурно-технологічних рішеннях із застосуванням трирівневої архіте-
ктури: “клієнт–сервер застосувань–сервер БД” ( СКБД Oracle) та розподілених застосувань, побудованих за прин-
ципами компонентного підходу. Наукова новизна одержаних результатів полягає у наступному:
− Визначені нових принципів моделювання й оптимізації задач керування ТП проектування ІС, починаю-
чи з аналізу потреб до створення відповідного програмного продукту.
− Розроблені формальні моделі керування управління проектуванням системи, ТП якої містить множину
процесів переробок різних сукупностей робіт проекту з оцінкою їх виконання відповідно до плану.
Ці результати сприяють розширенню, доповненню сучасних підходів МП по створення ІС методичними
рекомендаціями щодо проектування такого класу об’єктів як СУДз врахуванням специфіки їхнього функціону-
вання.
2.2. Принципи керування проектуванням ІС “ЗНЗ”. ІС “ЗНЗ” належить до складних об’єктів, які міс-
тять велику кількість даних та документів, зв’язність інформаційних компонентів, а також залучення до процесів
5
проектування різних спеціалістів для урахування специфіки та особливостей керування цими процесами. Керу-
вання проектуванням таких ІС виконується з використанням принципів та методів математичного програмуван-
ня, стохастичних мережних моделей та моделей, побудованих на статистичних даних, які підтримують загальні
методи вирішення задач цього класу [4]. Однак для розробки таких ІС ці принципи та моделі не є достатніми.
В результаті проведеного дослідження, запропоновані нові принципи моделювання й оптимізації задач ке-
рування проектуванням ІС, починаючи з аналізу потреб до створення відповідного програмного продукту. Для
цього розроблена формальна модель керування проектуванням системи, ТП якої містять множину процесів пере-
робок різних сукупностей робіт з оцінкою їх виконання відповідно плану (або графіку робіт), що наближає цей
метод до вимог спіральної моделі розробки програмних систем, коли є можливість повернення до вже виконаних
ТП.
Формальна модель визначає процес керування проектуванням їз послідовності дій, які виконуються у зада-
них умовах. Вона належить до класу динамічних систем з великою кількістю елементів, складними зв'язками між
ними і стохастичним характером їх поведінки. Постановку задачі керування проектом створення СУД зроблено
таким чином.
Нехай задано варіант плану (Х) виконання комплексу робіт із проектування ІС за такими даними:
– укрупнений сітковий графік виконання В, що складається з послідовності виконуваних робіт(li ∈ L);
– характеристика кожної li - роботи , її обсяг qi і виду Wi ,
– сукупність ресурсів R =< RL, RS >, що включають трудові RL і матеріальні RS, у тому числі кількість і їх
види;
− норми споживаних ресурсів по видах робіт NRi ∈ NR;
− закон розподілу випадкових величин F = {F1,..., Fr}, що характеризують вплив випадкових факторів:
помилки при виконанні робіт ( збої, ремонт технічних засобів, підмов програмних засобів, тощо).
Потрібно для заданого моменту часу усередині планового періоду [t0,T] визначити величину Y із вірогід-
ністю Р і такими очікуваними характеристиками ТП:
− терміни завершення окремих робіт і імовірність закінчення роботи в заданий термін;
− обсяг необхідних ресурсів (загальний і по кожній роботі) та обсяг робіт з урахуванням переробок доку-
ментів на ТП за формулою:
Y = Y (X (B, R, L, NR ), F, t0 , T ) (1)
Припустимо, що варіант плану Х належить області D, тобто X ∈ D і K(X) – критерій оптимальності варіан-
тів плану. Ставиться задача знайти такий оптимальний варіант плану
X* ∈ D, при якому мінімізується заданий критерій
K (X*) = min K (X) (2)
X∈D
Основні задачі визначення плану Х так сформулюємо з використанням формул (1, 2):
1) при заданих R, B, L, NR, F, t0, T складається такий план Х, щоб вихідні параметри цього пла-
ну знаходилися в області YD
з задоволенням співвідношення:
Y = Y(X)∈YD (3)
2) план комплексу робіт B вибирається так, що він буде оптимальним при заданому і рішенні на задачі (2).
Виконання плану робіт згідно змісту ТП супроводжується оперативним контролем для визначення розбі-
жності між фактичним станом ТП та значеннями його параметрів в момент t згідно плану Х. Коли є розбіжно-
сті, здійснюється корекція плану шляхом визначення значення Х*, виходячи з поточного стану процесу і спів-
відношення (2) чи (3).
Для ефективного вирішення задач керування ТП розробки ІС запропоновано модель ТП , яка включає
всі види робіт В, необхідні при виконанні процесу створення, проміжні стани ТП, функції оцінки ризику, ви-
трат, вартості з урахуванням внеску виконавців (їхнього інтелекту), випадкових факторів (збоїв, відмов, ремонту
технічних засобів тощо). Окрім того, в цю модель можуть включатися нормативи, характеристики операцій та
властивості конкретних ТП.
Відомі моделі терміну і витрат за підходом Боєма на етапах ЖЦ базуються на статистичних даних проек-
тів, які виконуються за кордоном. Для нас найбільше підходять імітаційні моделі ТП, для яких додаються такі
вимоги:
підтримка усіх фаз ЖЦ;
− включення усіх видів робіт на фазах ЖЦ;
− облік виконавців, їх інтелекту, в тому числі простоїв через бюлетені тощо;
− облік стохастичного характеру процесу ЖЦ через випадковий характер ситуацій тощо.
Модель ТП базується на графовій моделі G={Zi,lj}, і=0…n, l – дуга, Zo – початок робіт, Zi – поточна робота,
Zn – кінець роботи. Ця модель визначена на множинах:
− множині типів елементарних робіт на процесі W = { W1 ,..., W n1 };
− множині станів технічних засобів S = { S1 ,..., Sn2 };
6
− множині ознак кваліфікації виконавців L = { L1 ,.., L n3 };
− імовірності P = { Pij }, i =1, n , j =1, n , в якій Pij – імовірність повернення виконання для типу роботи Wi
до вершини Zj. Тобто імовірність переробки окремих робіт системи, починаючи з події у вершині Zj, залежить
від виявлення помилок, відмови технічного засобу Si, зміні кваліфікації Li або сукупності переходів, що обумов-
люються станом технічних засобів, кваліфікацією виконавців ТП , видами робіт Wi, тобто вимог до ІС під час
виконання деякої роботи Wi.
Проаналізовано виникнення різних ситуацій (збої, хвороби виконавців тощо) при виконанні процесу, які
потребують повернення на попередні етапи ТП, як це робиться в спіральних моделях для внесення змін в об-
робку результатів на попередніх етапах розробки. В зв’язку з цим для цієї моделі визначається граф повернення V
і будується граф робіт В*, які визначають схему проекту з припущенням, що керування за виконанням робіт буде
проводитися по заздалегідь складеному сітковому графіку, який має таке тлумачення. Нехай є проект, що скла-
дається з робіт Lj (j = 1, m). Для кожної роботи задано її обсяг. Подія, що задається вершиною Z1, означає поча-
ток робіт (дуги виходять з Z1). Кожний проміжний стан у вершині Zl означає закінчення роботи, вхідної до Zl,
і початком робіт, вихідної з Zl. Настання події Zh означає закінчення всіх робіт.
Означення. Планом виконання проекту називається кортеж <G, ψ, Ω, γ>, в якому
< G ψ, Ω > – сітковий графік робіт;
γ : N → F ψs х Fψi х Fψn х R+ х Р – відображення, яке задається на множинах функцій
F ψs : S → N, Fψl : L → N, Fψn : S х L → R+ та множині натуральних чисел N.
Дамо інтерпретацію плану виконання проекту ІС відповідно до заданих сітковим графіком < G, ψ, Ω > і
умові, що кожній дузі графу G поставлено у відповідність
γ (li) = < ψS
i (S1 ), ..., ψs
i (Sn2 ),
ψL
i (L1 ), ..., ψl
i (Lns ),
ψn
i (V1 ), ..., ψn
i (Vnz ),
ψn
i (ln1 ), ..., ψn
i (l n3, λi, Pi )>,
де ψS
i (Sj) – кількість ТЗ виду Sj;
ψL
i (L1) – кількість співробітників LJ -кваліфікації;
ψn
i (VJ) – норми споживання ресурсів для виду робіт Wj;
λ i – коефіцієнт прискорення робіт при повторному використанні готових компонентів;
Pi – імовірність існування дуги li на графі G.
Таким чином, формалізованим описом процесу проектування ІС у загальному вигляді є кортеж:
< G, ψ, Ω, γ >. (4)
У термінах запропонованої моделі процесу проводиться уточнення задач (1)- (3):
1. Нехай відповідно до (4) задано план проекту і потрібно визначити для періоду
[t0, T ] з вірогідністю Р імовірності виконання проекту в плановий термін P(t < T) = t (G, ψ, Ω, γ , t0)
і математичне тлумачення терміну закінчення робіт є: M(t) = M (t (B, ψ, Ω, γ , to)).
2. Якщо заданий план проекту <B, ψ, Ω, γ , t0> і плановий період [t0, T ], то будується календарний план: ℜ
= ℜ (B, ψ, Ω, γ , to ).
3. Вибирається такий план X (G, ψ, Ω, γ , t0), в якому X = {X1,..., Xn} ∈ D, щоб він був оптимальним від-
повідно обраного критерію К і виконанню робіт на інтервалі часу [ to, T].
Критерій К залежить від часу виконання проекту Ті є: K(X )=minT.
X∈D
За допомогою параметра Rs уточнимо цей критерій: K (X ) = min RS, який дорівнює:
Rs = { r1
s ,..., rn
s }, ψs (Si ) ≤ ri
s. У випадку, коли S = L, одержуємо: K = min RL .
S∈D L∈D
4. Знайти такий розподіл ресурсів по роботах ψ (R), щоб з імовірністю α математичне чекання закін-
чення проекту Т відрізнялося від планового терміну не більше, ніж на величину з вірогідністю
P ( (M (t) - T ( < с) = α.
Запропонована модель забезпечує оцінку і вибір оптимальних параметрів ТП, дозволяючи імітувати реа-
льну функцію системи, збирати статистику в процесі імітації, одержувати розподіл ресурсів по роботах так,
щоб проект був виконаний у директивний термін.
2.3. Кероване проектування ІС “ЗНЗ”. На базі запропонованих в дослідження методик і моделей
управління проектуванням ІС та моделей практичної оцінки вартості ПЗ в 2001-2003 році здійснено кероване
проектування ІС “ЗНЗ”.
2.3.1. Загальна характеристика ІС “ЗНЗ”. Система розроблена на замовлення Міністерства освіти і нау-
ки України. Архітектурно-технологічні рішення ґрунтуються на трирівневій архітектурі, серверна платформа
включає 2 сервери (Windows Server 2000, Linux Mandrake 8.1), в якості СКБД використовується Oracle Enterprise
Edition 9i, в якості клієнтської платформи може бути Windows 95/98/NT4.0/2000/ХP з Браузе-
ри IE 4.0, Netscape 6.0 і вище. Застосування розроблені і функціонують з використанням Java Runtime Edition
1.4.1, Oracle JDBC Driver 9i та TomCat 4.0 в якості cерверу застосувань. Документи в сховищі головним чином
7
повнотекстові з нерегулярною структурою (закони, укази, постанови, накази, розпорядження, програми, переліки
тощо). Структура даних представлена таблицями класифікаторів та таблицями бізнес-процесів. Система під-
тримує виконання функцій по реєстрація документів, перегляду та сортуванню, організації пошуку (атрибутив-
ного, повнотекстового). Адміністрування інформаційного наповнення здійснюється через АРМ контент-
адміністратора, колективна робота та безпека підтримується через реєстрацію та авторизацію. В системі реалі-
зовані списки розсилки з періодичністю раз на тиждень для автоматичної доставки користувачам нових докуме-
нтів. Передбачена можливість отримання СD-версії ІС “ЗНЗ”, що забезпечує такий самий як у розподіленій
версії вев-інтерфейс та підтримує всю функціональність по роботі з документами. В якості СКБД в СD-версії ІС
“ЗНЗ” використовується MySql.
2.3.2. Модель плану проекту ІС “ЗНЗ”. Для вирішення задачі керування проектом задавався варіант
плану (Х) виконання комплексу робіт з визначенням укрупненого сіткового графіку Модель плану проекту
була побудована на вихідних даних, які визначалися трудовими ресурсами та матеріальними ресурсами проекту.
Для виконання проекту була сформована команда у складі менеджера проекту, економіста проекту,
експерт-аналітика в галузі середньої освіти (2 фахівця), системного аналітика-адміністратора, системниого адмі-
ністратора (2 фахівця), системного програміста (2 фахівця), веб-дизайнера, прикладного програміста (3 фахівця),
контент-адміністратора, програміста-тестувальника, оператора-тестувальника, оператора-сканувальника (2 фахі-
вця), оператора ведення баз даних, інженера-експулатаційника технічних засобів (3 фахівця).
Матеріальні ресурси проекту визначені по таких статтях кошторису: заробітна плата, нарахування на
заробітну плату, лінії зв'язку Укртелекому для доступу до Інтернет, каналу доступу до Інтернет128 Кбіт/с,
обладнання (комп’ютерне, комунікаційне, мережеве), матеріали, комплектуючі, відрядження, участь в науко-
во технічних конференціях, науково-технічна літератури, спеціалізовані видання,
В табл. 2 подано фрагмент вихідних даних плану проекту ІС “ЗНЗ”.
Таблиця 2.
Фрагмент вихідних даних плану проекту ІС “ЗНЗ”
№ Назва роботи Код Результат Параметри B Параметри V
Тmin Tmax Норми λλλλi Pi
0 Узгодження заяв-
ка-запиту на ви-
конання ІС “ЗНЗ”
0-1 Виграний тендер на
НДР
14 26 14 0.6 0.3
9 Проектування
архітектури
9-10 Функціональна мо-
дель серверної та
клієнтської частини
15 20 15 0.8 0.
3
10 Проектування
графічних ресур-
сів системи
10-14 Форми інтерфейсу
користувача, зага-
льний дизайн сайту
www.znz.edu-ua.net
25 30 28 0.2 0.5
20 Супроводження
системи
20-0 Актуалізовані б.д,
(Інтернет, СD вер-
сії)
Модифіковане про-
грамне забезпечення
визначається поза схемою проекту
Використання моделі плану проекту забезпечило відповідну якість керування проектом та оптимальне
використання наявних ресурсів, особливо трудових, в умовах нестабільного бюджетного фінансування проекту.
Для оптимізації сіткового графіку робіт була розрахована вірогідність P настання кінцевої події у заданий термін.
Розрахунок виконувався шляхом визначення математичного очікування та дисперсії на вихідних даних проекту.
Отримано значення вірогідності P, що дорівнює 0.47. Це значення знаходиться в інтервалі [0.35; 0.65], тобто
оптимізація сіткового графіка не була потрібна. Кінцевий термін розробки відповідав визначеному в моделі пла-
ну проекту без врахування затримки фінансування замовником на останньому етапі робіт.
В процесі виконання проекту важливим питанням було керування ризиками та розподіл фінансових кош-
тів. Останній великою мірою залежав від оцінки вартості ПЗ. Методика оцінка ПЗ змінювалася на різних стадіях
ЖЦ: на першому етапі ескізного проекту використовувалася методика функціональних точок та дані української
фірми “P5”, що розробила подібний проект по створенню інформаційного порталу http://www.nuvse.com. На етапі
реалізації ПЗ та повернення на попередні етапи ЖЦ проекту, пов’язане з уточненням схеми даних та новими вер-
сіями дизайну, використовувалися методика SLOC. Крім того, враховувалися можливості персоналу, який част-
ково був сформований із членів команди “P5” (системний адміністратора, системний програміст, веб-дизайнер,
прикладний програміст) та готових компонент у вигляді Java-cервлетів для доступу в базу даних СКБД Oraclre та
динамічного відображення документів із сховища на веб-сайт, які були розроблені цими фахівцями у межах по-
переднього проекту. За рахунок цього вдалося вийти на такий рівень технології щодо інструментарію, компонен-
тів, процесів (див. табл..1):
8
− ітераційна розробка;
− компоненто-орієнтований підхід;
− частково-інтегроване середовище,
− розмір: 60% на базі готових компонент, 40% на замовлення.
− типова ефективність проекту: у межах бюджету, перевищення термінів на квартал через затримку фі-
нансування замовником
Висновки
Головними результатами проведеного дослідження є створення цілісної концепції керованого проекту-
вання СУД, яка вирішує важливе наукове завдання щодо створення таких систем та мають суттєве значення для
розвитку теорії і практики автоматизації та електронної обробки документів.
Основний результат роботи полягає у формулюванні нових принципів моделювання задач керування ТП
проектування, визначена формальна модель керування проектом СУД, яка враховує ресурси та команду розроб-
ників, їх планування та корекції планів робіт по створенню ІС.
На основі цілісної концепції моделювання і керування проектом спроектована ІС “ЗНЗ”, яка успішно
функціонує: (згідно наказу МОН України №181/18 від 27.03.03 експлуатація системи здійснюється Інститутом
засобів навчання АПН України). Здійснення проекту ІС “ЗНЗ” продемонструвала достовірність і правильність
проектних рішень: з 2003 року надається авторизований доступ до інформаційних ресурсів www.znz.edu-ua.net
згідно договорів з управліннями освіти і науки обласних державних адміністрацій.
Література
1. Перевозчикова О.Л. Сучасні інформаційні технології. К.: 2002, Інститут економіки та права "Крок".
2. Уокер Ройс. Управление проектами по созданию программного обеспечения . М. Лори, 2002 – 424 с.
3. Боэм Б.У. Инженерное проектирование программного обеспечения. – М: Радио и связь, 1995. – 511 с.
4. Бабенко Л.П., Лавріщева К.М. Основи програмної інженерії. – К.: Знання, 2001. – 269 с.
5. Лешек А. Мацяшек. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML: Пер. с
англ. – М.: Вильямс, 2002. – 428 с.
6. Дин Леффингуэлл, Дон Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход.: Пер. с
англ. – М.: Вильямс, 2002. – 446 с.
|
| id | nasplib_isofts_kiev_ua-123456789-2275 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 1727-4907 |
| language | Ukrainian |
| last_indexed | 2025-12-07T19:00:20Z |
| publishDate | 2004 |
| publisher | Інститут програмних систем НАН України |
| record_format | dspace |
| spelling | Задорожна, Н.Т. 2008-09-17T11:45:20Z 2008-09-17T11:45:20Z 2004 Менеджмент проекту інформаційної системи ПІдтримки нормативно-правового забезпечення органів державного управління /Н.Т.Задорожна // Проблеми програмування. — 2004. — N 2,3. — С. 155-162. — Бібліогр.: 6 назв. — укр. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/2275 007.62-50 Аналізується менеджмент проекту інформаційних систем (ІС) управлінської діяльності на базі сучасних принципів керування ство-
 ренням програмного забезпечення. Визначена формальна модель проектного менеджменту таких систем. Наведено приклад застосування
 запропонованих принципів The information systems project management process to support for Government bodies is analyzed. The analyses is based on modern principles
 of software management project. The formal model for project management of information systems in this area is defined.
 The example using of the proposed principles is represented. uk Інститут програмних систем НАН України Методы и средства программной инженерии Менеджмент проекту інформаційної системи ПІдтримки нормативно-правового забезпечення органів державного управління Article published earlier |
| spellingShingle | Менеджмент проекту інформаційної системи ПІдтримки нормативно-правового забезпечення органів державного управління Задорожна, Н.Т. Методы и средства программной инженерии |
| title | Менеджмент проекту інформаційної системи ПІдтримки нормативно-правового забезпечення органів державного управління |
| title_full | Менеджмент проекту інформаційної системи ПІдтримки нормативно-правового забезпечення органів державного управління |
| title_fullStr | Менеджмент проекту інформаційної системи ПІдтримки нормативно-правового забезпечення органів державного управління |
| title_full_unstemmed | Менеджмент проекту інформаційної системи ПІдтримки нормативно-правового забезпечення органів державного управління |
| title_short | Менеджмент проекту інформаційної системи ПІдтримки нормативно-правового забезпечення органів державного управління |
| title_sort | менеджмент проекту інформаційної системи підтримки нормативно-правового забезпечення органів державного управління |
| topic | Методы и средства программной инженерии |
| topic_facet | Методы и средства программной инженерии |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/2275 |
| work_keys_str_mv | AT zadorožnant menedžmentproektuínformacíinoísistemipídtrimkinormativnopravovogozabezpečennâorganívderžavnogoupravlínnâ |