Інфраструктура програмного проекту

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

Складовими ресурсами цієї інфраструктури є такі:

• — техніка та комунікації (комп'ютери, файли і сервери; локальні та глобальні мережі; електронна пошта (e-mail); техніка налагодження; офісна техніка тощо).
• — загальносистемне ПС та інструменти (клієнт/серверні технології; ОС; системи документообігу; утиліти; засоби захисту інформації, CASE-інструменти, системи програмування, графічні інструменти, СКБД тощо);
• — інформаційні ресурси та методології, що визначають процеси розроблення проекту з використанням інструментів керування проектами та засобів Internet (веб-ресурси, веб-семантика тощо);
• — стандарти програмної інженерії з ЖЦ, визначення інтерфейсів, між проектної взаємодії, якості, вимірювання тощо;
• — кадрові питання відображають усе, що пов’язано з підготовкою персоналу для виконання різнопланових робіт у проекті, а також з вивченням сучасних систем знань (ядро знань SWEBOK, PMBOK, засоби Інтернету тощо) для досягнення необхідного рівня реалізації проекту.

Організаційне забезпечення в інфраструктурі проекту вміщує велику кількість груп персоналу, в обов’язки яких входять ведення, планування, контроль і оцінювання процесу ЖЦ розроблення ПС. До них відносять такі групи:

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

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

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

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

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

Менеджер підбирає для вдалої організації ведення проекту підбирає стиль ведення проекту, наприклад, стиль фірми IBM, який склався при розробленні проекту всесвітньо відомої ОС IBM-370. У ньому проектування ОС і розроблення її продукту виконував головний програміст і група програмістів.

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

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

Альтернативна структура ведення проекту описана Вейнбергом (Weinberg), так зване знеособлене програмування, коли всі несуть однакову відповідальність за якість продукту. У проекті не концентруються на персоналіях, критиці піддається програмний продукт, а не члени групи. Така структура підходить для маленьких груп програмістів.

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

Моделювання робіт у проекті. У військових відомствах розроблено загальну структуру команди для створення інтегрованого продукту (Integrated Product Development Team).

В цьому проекті менеджер керував розподілом обов’язків і встановлював строки для виконання трьох однакових за розміром завдань проекту, що пов’язані з моделюванням робіт у процесах проектування, аналізу й тестування.

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

Під час розроблення проекту обов’язки і ролі співробітників постійно змінюються. Це зручно для проекту, у якому часто змінюються плани, для них встановлюються строки в межах тижня або навіть годин. Показником того, якою мірою виконано завдання, є діаграма запланованих і реально виконаних робіт. Часто ця модель обов’язків поєднується з моделлю «з рук у руки» (hand-off). Вона припускає передачу результатів робіт однієї групи для роботи іншій групи.