Тема Основи управління проектами t rojec e P

Тема: Основи управління проектами t rojec e P m nage Ma t n ation nform logie I chno Te s 1. 2. 3. 4. 5. 6. 7. Проект і сутність проектної діяльності. Міжнародні та національні стандарти з управління проектами. Класифікація проектів. Життєвий цикл і фази проекту. Моделювання і стандарти життєвого циклу проектів інформатизації. Учасники й оточення проекту. Методичні засади структуризації проекту.

Питання 5. Моделювання і стандарти життєвого циклу проектів інформатизації

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

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

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

Узагальнена модель життєвого циклу: 2. Створення і впровадження системи Вона може бути побудована в залежності від прийнятої моделі ЖЦ проекту. Головну роль протягом цієї фази відіграє організація-розробник.

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

Каскадна модель ЖЦ ІС характеризується структурою впорядкованих стадій з яких складаються стадії створення і впровадження. Така впорядкованість передбачає, що всі передбачені роботи повинні виконуватись настільки ретельно, щоб не переглядати прийняті рішення. Модель містить тільки цикл на стадії супроводу. Склад і назва технологічних стадій у різних авторів різна. Відмінності зводяться до ступеню деталізації. Американський стандарт стадій створення автоматизованої системи військового призначення DOD-STD-2167 A передбачає стадії, наведені на наступному слайді.

Каскадна модель життєвого циклу ІС

Каскадна модель ЖЦ ІС Переваги каскадної моделі: Недоліки каскадної моделі: 1) Детермінованість 1) Від затвердження ТЗ до моделі; впровадження готового продукту минає багато 2) Чітка регламентованість часу. Існує ризик, що (що спрощує управління вимоги користувачів проектом, особливо зміняться і не будуть контроль за виконанням). задоволені. 2) Можливі випадки, коли реальні потреби залишилися незмінними, але були неправильно або недостатньо використані користувачем під час розробки ТЗ.

Спіральна модель ЖЦ Передбачає багаторазове проходження тих самих стадій проекту доти, доки він не буде задовольняти замовника. Ця модель відображає ітеративний характер, властивий процесу створення таких складних проектів, якими є програмне забезпечення ІС. На кожній ітерації створюють діючий прототип, піддають критичній оцінці. На заключній ітерації прототип приймають за остаточний варіант системи. Якщо проект великий, то зазвичай виділяють в ньому обмежену підсистему, яку доцільно розробляти використовуючи спіральну модель. Ця модель використовується у випадках, коли замовник, розробник і користувач - одна особа, продукт для масового споживача

Спіральна модель життєвого циклу Остаточний варіант Випробування та оцінка Реалізація Аналіз вимог Проектування

Спіральна модель ЖЦ Переваги - відсутність недоліків каскадної моделі, так як можна врахувати вимоги, що змінилися. Недоліки - складність планування та організації робіт, значні витрати ресурсів при розробці великих проектів. Використовується для невеликих проектів, існує велика невизначеність відносно вимог користувача.

Інші моделі Проміжними між каскадною і спіральною моделями є : 1) Метод швидкого прототипу; 2) Метод послідовного нарощування функцій; 3) Еволюційна модель; 4) Модель заснована на повторному використанні компонент; 5) Модель заснована на автоматизованому синтезі програм.

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

1. Метод швидкого прототипу Основне призначення - полегшити виявлення вимог користувача. Прототип після розробки ТЗ не використовується, а в іншому ця модель ЖЦ співпадає з каскадною. Приклад такого підходу - Британський стандарт SSADM. Він реалізовує модель схожу на каскадну, однак передбачає багатократне коригування документів.

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

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

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

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

4. Модель заснована на повторному використанні компонентів (закінчення) Унікальні алгоритми обробки інформації чи суб'єктивні знання - евристики, якими користуються експерти при розв'язанні складних задач, - за допомогою стандартних програм описати навряд чи можливо. Тому модель, заснована на повторному використанні компонентів, є ідеалізацією і в чистому вигляді не використовується. Нині, у зв'язку з поширенням об'єктноорієнтованого підходу до розробки ІС, вона набуває все зростаючого значення.

5. Модель заснована на автоматизованому синтезі програм Ця модель заснована на трансляції спеціально розроблених програм на мові високого рівня в машинні програми. Ця концепція заснована на знаннях як про предметну область, так і процес створення програмних засобів. На відміну від інших підходів вона вимагає досить високих первинних витрат на побудову моделі знань та особливо на створення інструментальних засобів їх підтримки, що збільшує вартість розробки. Разом із тим автоматизований синтез програм дозволяє різко скоротити всі види витрат на кожний подальший зразок ІС і реалізувати високу якість програмного продукту.

Вибір ЖЦ ІС Для вибору необхідно порівняти сильні і слабкі сторони. Вибір залежить від того, хто є замовником ІС. Якщо це - ринок або замовник - не державна організація, то вибір диктується тільки логікою здорового глузду та використовуваною методологією розробки ІС (MSF, CDM Oracle тощо). Якщо проект розробляється за державним замовленням, то необхідно дотримуватись ДСТУ, тобто треба застосовувати каскадну модель.

Методика Oracle Custom Development Method (CDM) підтримує три моделі життєвого циклу: 1) “Класичну” – Класичну передбачені всі роботи/задачі та етапи; 2) “Прискорена розробка” (Fast Track) розробка – зорієнтована на використання інструментів моделювання та програмування Oracle (Designer/2000, зокрема), призначена для порівняно невеликих та середніх проектів. “визначення вимог” (етап стратегії); аналіз вимог (формулювання детальних вимог до системи); проектування (перетворення вимог в детальні специфікації системи); реалізація (написання та тестування додатків); впровадження (установка системи, підготовка до початку експлуатації); експлуатація (підтримка та спостереження за додатком, планування майбутніх функціональних розширень). 3) “Полегшений підхід” – підхід рекомендується у випадку малих проектів, можливості швидкого прототипування додатків. Передбачають поділ проекту у часі на три фази: 1. аналіз вимог; 2. проектування та створення системи; 3. передача в експлуатацію/ впровадження.

Основні процеси методики Oracle Custom Development Method: 1] аналіз вимог – процес визначає бізнес- та системні вимоги до додатку; 2] аналіз існуючої системи – процес визначає і формулює існуюче технічне середовище для визначення необхідних змін; 3] технічна архітектура системи – процес визначає елементи технічної бази системи, що розробляється; 4] проектування і створення БД – процес забезпечує проектування і створення реляційної бази даних, включаючи, наприклад, питання ефективної індексації і безпеки (секретність) на рівні об'єктів БД; 5] проектування і створення модулів ПЗ – основний процес, включає проектування додатків і створення програмного коду; 6] перетворення даних – цілі процесу – міграція, перетворення і тестування всіх існуючих даних, які необхідні для роботи нової системи; 7] документування – процес забезпечує створення якісної текстової та on-line документації для користувачів і адміністраторів, а так само технічних описів проекту; 8] тестування – процес забезпечує спільне тестування якості всіх елементів системи, як окремих модулів, так і результатів їх об'єднання; 9] навчання – процес забезпечує навчання і тестування користувачів і адміністраторів; 10] передача замовнику – процес включає такі задачі, як розробка плану інсталяції системи, підготовка технічного середовища, організацію процесу "згортання" існуючої системи; 11] підтримка системи – цілі процесу – моніторинг і розв'язання проблем, заміна версій з виправленими помилками, оцінка роботи системи і планування поліпшень.

Взаємозв'язок фаз та процесів методики Oracle Custom Development Method: Проектування Аналіз вимог та створення системи Аналіз вимог (RD) Аналіз існуючої системи (ES) Технічна архітектура системи (TA) Проектування і створення бази даних (DB) Проектування і створення модулів ПЗ (MD) Перетворення даних (CY) Документування (DO) Тестування (TE) Навчання (TR) Передача замовнику (інсталяція) (TS) Підтримка (PS) Передача в експлуатацію

Метод Oracle Project Development Method (PJM ) призначений для управління проектами в області інформаційних технологій. Мета – забезпечити структурну основу для планування, оцінки, управління і контролю проектів будь-яких типів. Основні процеси, що розглядаються в PJM: 1) Контроль і Звіти – процес містить задачі, що допомагають визначити обсяг робіт і методи проведення, управляти можливими змінами і контролювати ризик; крім того він визначає управління планом проекту і звіти про хід проведення проекту); 2) Управління Роботами – задачі цього проекту визначають і контролюють стан всіх робіт, що виконуються по проекту. Крім цього, забезпечують “фінансовий погляд” на проект; 3) Управління Ресурсами – процес забезпечує оптимальний підбір персоналу, що бере участь в проекті, а також організує інфраструктуру для проведення проекту); 4) Управління Якістю – процес повинен забезпечити “вимірювання якості” і гарантувати задоволення не тільки вимог, але і очікувань замовника на протязі всього проекту; 5) Управління конфігурацією – задачі процесу допомагають організувати зберігання і управління всіма елементами, що створюють хід проекту.

Етапи життєвого циклу: 1) планування проекту: задачі цієї категорії відносяться до предметної області якості, часу і вартості проекту загалом – визначається організаційна структура і зони відповідальності учасників проекту; 2) планування фази: задачі цієї категорії доповнюють і деталізують плани проекту для конкретної фази; 3) управління фазою: ці задачі виконуються паралельно з виконанням робіт по проекту, здійснюють функції моніторингу і звітності на протязі фази); 4) завершення фази: ці задачі завершують проект і забезпечують підписання всіх необхідних документів по цій фазі; 5) завершення проекту: врегулювання всіх спірних питань і забезпечення успішного завершення проекту. Планування проекту Контроль і звіти Правління роботами Управління ресурсами Управління якістю Управління конфігурацією Управління фазами Планування фази Управління фазою Завершення фази Завершення проекту

Міжнародний стандарт ISO/IEC 12207 – це базовий стандарт процесів ЖЦ ПЗ, орієнтований на будь-які види ПЗ та типи проектів автоматизованих систем, куди входить ПЗ як частина стандарту і визначає стратегію і загальний порядок створення та експлуатації ПЗ. ISO/IEC 12207 охоплює ЖЦ від концептуалазації ідеї до завершення ЖЦ. Згідно з ним: Система – це об'єднання одного або більше процесів, апаратних засобів, програмного забезпечення, обладнання і моделей з метою забезпечення можливості задоволення певних потреб або цілей. В ISO/IEC 12207 описано 5 основних (базових) процесів: 1) Процес придбання (замовлення): визначає дії підприємства, яке купує систему, програмний продукт або сервіс програмного забезпечення. 2) Процес постачання: визначає дії підприємства, яке поставляє покупцеві систему, програмний продукт або сервіс ПЗ. 3) Процес розробки: визначає дії підприємства-розробника, яке формулює принципи побудови програмного виробу і розробляє програмний продукт. 4) Процес функціонування: визначає дії підприємства-оператора, яке обслуговує систему (а не тільки ПЗ) в процесі функціонування в інтересах користувачів. 5) Процес супроводу: визначає дії персоналу супроводу, який забезпечує супровід програмного продукту, що включає: управління модифікаціями підтримку його поточного стану та функціональної інсталяцію та вилучення програмного виробу з

ISO/IEC 12207 описує 8 допоміжних процесів, які підтримують інші процесів процеси ЖЦ, є його частиною і забезпечують відповідну якість проекту: 1) Розв'язання проблем 5) Процес верифікації; 2) Документування ; 6) Процес атестації; 3) Управління конфігурацією; 7) перевірка відповідності спільної оцінки (об'єднаних оглядів); 4) Забезпечення якості; 8) процес аудиту (ревізії). Група забезпечення якості Крім того, в ISO/IEC 12207 описано такі організаційні процеси: процеси 1] процес управління; 2] процес створення інфраструктури – визначає дії по створенню інфраструктури, яка підтримує процеси ЖЦ; 4] процес навчання; 3] процес удосконалення процесів ЖЦ; 5] Процес адаптації, який визначає дії, необхідні для адаптації стандартів до умов конкретного проекту.

Опис основних процесів життєвого циклу програмного продукту А 1 Процес замовлення Виконавець – Замовник Дії: 1. 1. Ініціювання; 1. 2. Підготовка запиту щодо пропозицій (тендеру); 13. Підготовка та коригування контракту; 1 4. Нагляд за постачанням; 1. 5. Приймання та завершення

Опис основних процесів життєвого циклу ПП: ініціювання Завдання Примітка Описати концепції або потреби щодо замовлення, розроблення чи вдосконалення системи, програмного продукту або програмної послуги 1. 1. 1. Визначити та проаналізувати вимоги до системи. Вимоги до системи повинні містити вимоги з боку виробничого процесу, організації та користувача, а також вимоги щодо безпеки, захисту та інші критичні вимоги разом із відповідними стандартами та процедурами щодо розроблення, випробування та погодження 1. 1. 2. 1. 1. 3. Затвердити результати аналізу вимог Замовник може здійснювати визначення вимог до програмного забезпечення самостійно або може передати виконання "цього завдання" постачальникові Якщо замовник для виконання аналізу системних вимог наймає постачальника Для виконання завдань, наведених у підпунктах 1. 1. 2 та 1. 1. 3, повинен використовуватися процес розроблення (табл. А 3).

Опис основних процесів життєвого циклу ПП: ініціювання Завдання Примітка Розглянути варіанти замовлення, виходячи з аналізу відповідних критеріїв, включно з ризиком, вартістю та вигодою, для кожного варіанту. Варіанти містять: а) купівлю повністю готового для використання програмного продукту, що відповідає вимогам; б) розроблення програмного продукту або отримання програмних послуг в рамках організації; в) розроблення програмного продукту або отримання програмних послуг через контракт; г) комбінація варіантів а), б) та в) цього переліку; д) удосконалення існуючого програмного продукту або послуги. 1. 1. 4.

Опис основних процесів життєвого циклу ПП: ініціювання Завдання 1. 1. 5. Впевнитись, що: а) вимоги щодо програмного продукту задовольняються; б) документація є у наявності; в) права щодо використання та володіння, а також патентні, гарантійні та ліцензійні права забезпечуються; г) підтримка програмного продукту у майбутньому планується. 1. 1. 6. Підготувати, задокументувати та виконати план замовлення. Визначити та задокументувати стратегію та умови приймання (критерії) 1. 1. 7. Примітка Якщо замовляється готовий до використання програмний продукт План повинен містити: а) вимоги щодо системи; б) застосування планованої системи; в) тип контракту, що буде застосовано; г) відповідальність організацій-учасників; д) концепцію підтримки, що буде використана; е) враховані ризики разом з методами управління ризиками.

Опис основних процесів життєвого циклу ПП: підготовка запиту щодо пропозицій (тендеру) Завдання Примітка 1. 2. 1. Задокументувати вимоги щодо замовлення (наприклад, запит щодо пропозиції), зміст якого залежить від варіанту замовлення, вибраного згідно з Пунктом 1. 1. 2. Документація щодо замовлення повинна, містити: а) системні вимоги; б) опис сфери застосування; в) інструкції для учасників тендеру; г) перелік програмних продуктів; д) терміни та умови; е) умови нагляду за субпідрядами; ж) технічні обмеження (наприклад, цільове середовище). Визначити, які процеси, дії та завдання, що входять до цього стандарту, відповідають проекту, і відповідним чином їх пристосувати. Визначити сферу завдань, які стосуються контракту. Головним чином, треба визначити процеси підтримки та організаційні процеси життєвого циклу, а також, розподіл відповідальності (якщо вона покладається на когось іншого, крім постачальника), з тим, щоб постачальники мали змогу у своїх пропозиціях вказати підхід до кожного з визначених підтримувальних і організаційних процесів. 1. 2. 2.

Опис основних процесів життєвого циклу ПП: підготовка запиту щодо пропозицій (тендеру) Завдання Визначити проміжні етапи контракту, на яких буде здійснюватися перегляд та аудит перебігу робіт постачальника, як складова частина нагляду за процесом замовлення (Процес спільного перегляду, Процес аудиту). 1. 2. 3. Вимоги щодо замовлення слід передати організації, яку обрано для виконання дій щодо замовлення. 1. 2. 4. Примітка Зазначається у документації на замовлення

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

Стандартом ISO/IEC 12207 передбачено 11 класів характеристик якості: якості 1) функціональні й інші можливі специфікації, включаючи виконання, фізичні характеристики та умови середовища експлуатації; 2) зовнішні зв'язки (інтерфейси); 3) вимоги кваліфікації; 4) специфікації надійності, включаючи специфікації, пов'язані з методами функціонування і супроводу, взаємодії з зовнішнім середовищем та вірогідністю травм персоналу; 5) специфікації захищеності, включаючи специфікації, пов'язані з дотриманням точності інформації; 6) людські фактори специфікації з інженерної психології (ергономіки), включаючи пов'язані з ручним управлінням, взаємодією людини та обладнання, обмеженнями на персонал та дії, що потребують концентрації людської уваги, які є чутливими до помилок людини та навчання; 7) визначення даних та вимог бази даних; 8) вимоги до установки та прийомки ПП, що поставляється в місцях функціонування та супроводу; 9) документація користувача; 10) робота користувача і вимоги виконання; 11) вимоги сервісу користувача.

Порівняльна характеристика CDM та ISO 12207 CDM Примітки Основні процеси: Процес придбання розробником (замовником) Немає Процес поставки Немає В CDM є процес СV – перетворення даних Процес розробки. Визначає RD, ES, TA, DB, MD, (DO), дії підприємства(TR), TS розробника, яке розробляє принципи побудови ПВ і ПП (в контексті створення системи) В дужках показано процеси DO – документування та TR – навчання, які відображені в інших процесах ISO 12207 Процес експлуатації Немає В організація-оператор розробляє план і гарантує відповідність плану Процес супроводу PS ISO передбачає розвиток, як елемент супроводу, що викликає новий процес, в CDM в такому трактуванні повномасштабний розвиток не передбачено

Порівняльна характеристика CDM та ISO 12207 CDM Допоміжні процеси: Процес документування DO – документування Процес управління конфігурацією ПЗ Примітки Немає Процес забезпечення якості. А також процеси: Øверифікація Øатестація Øсумісна оцінка Øаудит Процес вирішення проблем TE – тестування, Oracle PJM ISO використовує можливість застосувати інші міжнародні стандарти, наприклад ISO 9000 Є в CDM Організаційні процеси: Процес управління Oracle PJM Процес створення інфраструктури Oracle PJM Удосконалення процесів ЖЦ Немає Процес навчання TR – навчання В ISO 12207 передбачено зв'язок з ISO 9000

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

3) Використання ISO 12207: а) фіксує необхідність організаційного відокремлення дій, пов'язаних з “виготовленням” ПЗ і АС від деяких видів робіт, пов'язаних з гарантуванням якості; б) фактично визначає конкретну відповідальність керівників організації і проектів за встановлення відповідної професійної культури, технології і вимог до якості розробок, або ж за відмову від цілеспрямованої діяльності з вирішення цих проблем. в) побудова профілів ЖЦ проекту на основі ISO 12207 зазначеним чином може зробити проектні роботи більш дорогими. Вартість виросте також через проведення дій з гарантування якості. На перший погляд – це непотрібні ускладнення і ризики в проектуванні АС, яке і без того відносять до діяльності з підвищеним ризиком.

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

Питання 6. Учасники й оточення проекту.

Склад учасників проекту, їх роль, розподіл їх функцій і відповідальності залежать від типу, виду, масштабу і складності проекту, а також від фаз ЖЦ проекту. Жорстких регламентів по складу учасників проекту не існує. Незмінними можна вважати наступні функції по здійсненню проекту, а отже і такий склад основних учасників: - проект повинен бути осмислений, “придуманий" і ініційований, значить у нього повинен бути ініціатор; - проект повинен мати головну зацікавлену особу (організацію), тобто сторону, яка є майбутнім власником і користувачем результатами проекту і несе за нього відповідальність. У нашій термінології замовник = власник + користувач; - здійснення проекту вимагає залучення інвестицій, значить у нього повинні бути інвестори; - проект треба готувати і здійснювати, значить у нього повинні бути виконавці; - внаслідок реалізації більшості проектів повинне щось вироблятися або надаватися послуги, значить у проекту повинні бути свої продавці, виробники і споживачі; - проектом треба управляти, значить у проекту повинні бути менеджери.

Принципова схема учасників проекту

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

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

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

Функції основних учасників проекту Керівник проекту (менеджер): юридична особа, якій замовник і інвестор делегує повноваження з керівництва роботами по здійсненню проекту, а саме: плануванню, контролю і координації робіт всіх учасників проекту. Склад функцій і повноважень керівника проекту визначається контрактом із замовником. Однак, перед керівником проекту і його командою звичайно ставиться задача всеосяжного керівництва і координації робіт протягом ЖЦ проекту до досягнення певної мети проекту і результатів при дотриманні встановлених термінів, бюджету і якості.

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

Функції основних учасників проекту Контрактор (генеральний контрактор): сторона або учасник проекту, що вступає у відносини з замовником і який бере на себе відповідальність за виконання робіт за контрактом. Це може бути весь проект або його частина. Мета контрактора - отримання максимально можливого прибутку. Функції контрактора: укладання контракту із замовником (інвестором), відбір і укладання договорів з субконтракторами, забезпечення координації їх робіт, прийняття і оплата робіт співвиконавців. Контрактором може бути керівник проекту або інші активні учасники проекту. Субконтрактор: вступає у договірні відносини з контрактором або субконтрактором більш високого рівня, несе відповідальність за виконання робіт і послуг відповідно до контракту.

Функції основних учасників проекту Проектувальник: юридична особа, що виконує за контрактом проектно-дослідницькі роботи в рамках проекту. Вступає у договірні відносини з генеральним контрактором або безпосередньо із замовником. Генеральний підрядник: юридична особа, чия пропозиція прийнята замовником (як правило, для будівельних проектів). Тому звичайно генеральним підрядником є будівельна і проектно-будівельна організації. Генеральний підрядник несе відповідальність за виконання робіт відповідно до контракту, підбирає і укладає договори з субпідрядниками на виконання окремих робіт і послуг. Постачальники: субконтрактори, що здійснюють різні види постачання на контрактній основі.

Функції основних учасників проекту Ліцензори: організації, що видають ліцензії на право володіння земельними ділянками, ведення торгів, виконання певних робіт і послуг, використання “ноухау". Органи влади: сторона, що висуває і підтримує екологічні, соціальні і інші висуваються суспільством і державою сторони проекту і що задовольняє свої інтереси шляхом отримання податку від учасників проекту. Власник земельної ділянки: юридична або фізична особа, що є власником землі, що бере участь у проекті. Виробник кінцевої продукції: здійснює експлуатацію створених основних фондів і виробляє кінцеву продукцію. Бере участь у всіх фазах проекту. У багатьох випадках є замовником і інвестором. Головна мета – прибуток.

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

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

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

Проект та його оточення

Схема оточення проекту

Оточення проекту у складі підприємства

№№ п/п Експертна оцінка ступеню впливу факторів оточення на різні типи проектів Сфери впливу оточення проекта Політика Еко номіка Сус Запіль кон ство і порядок Нау ка і тех -ніка Ку ль тура При рода Еко логія Інфраст рукт ура Типи і види проектів 1 Соціальні 3 3 1 3 1 2 2 2 Економічні 3 3 2 3 1 2 0 1 1 3 Організаційні 2 3 2 3 2 1 1 4 Інноваційні 1 2 3 3 1 1 1 5 Інвестиційні 1 3 2 1 3 3 3 10 14 9 12 7 8 8