Інфраструктура програмного проекту
Важлива роль виконував бібліотекар, який зберігав усі проміжні результати роботи команди (документи, тести, модулі, їхні версії тощо) в бібліотеці проекту. Це надавало можливість усім членам команди сконцентруватися на їхній безпосередній роботі створювати необхідні дані для їхнього зберігання у архіві системи. Менеджер підбирає для вдалої організації ведення проекту підбирає стиль ведення… Читати ще >
Інфраструктура програмного проекту (реферат, курсова, диплом, контрольна)
Інфраструктура проекту в організації - це інтегрований набір загальнодоступних технічних, технологічних і методологічних ресурсів, використання яких робить можливим процес виконання проекту колективом, що створюються за договором з замовником.
Складовими ресурсами цієї інфраструктури є такі:
- — техніка та комунікації (комп'ютери, файли і сервери; локальні та глобальні мережі; електронна пошта (e-mail); техніка налагодження; офісна техніка тощо).
- — загальносистемне ПС та інструменти (клієнт/серверні технології; ОС; системи документообігу; утиліти; засоби захисту інформації, CASE-інструменти, системи програмування, графічні інструменти, СКБД тощо);
- — інформаційні ресурси та методології, що визначають процеси розроблення проекту з використанням інструментів керування проектами та засобів Internet (веб-ресурси, веб-семантика тощо);
- — стандарти програмної інженерії з ЖЦ, визначення інтерфейсів, між проектної взаємодії, якості, вимірювання тощо;
- — кадрові питання відображають усе, що пов’язано з підготовкою персоналу для виконання різнопланових робіт у проекті, а також з вивченням сучасних систем знань (ядро знань SWEBOK, PMBOK, засоби Інтернету тощо) для досягнення необхідного рівня реалізації проекту.
Організаційне забезпечення в інфраструктурі проекту вміщує велику кількість груп персоналу, в обов’язки яких входять ведення, планування, контроль і оцінювання процесу ЖЦ розроблення ПС. До них відносять такі групи:
- — техніко-технологічної підтримки (вивчення ринку, придбання Case, ПС, консультації співробітникам, тощо);
- — захисту інформації (забезпечення засобами захисту і перевірки інформації в проекті);
- — технологічної служби (супроводження процесу проекту, нормативнометодична підтримка ЖЦ, побудова графіків робіт, контроль тощо);
- — якості (SQA-група), у функції якої входить планування та виконання дій ЖЦ, дотримання дисципліни створення проекту, перевірки робіт у контрольних точках проекту, контроль якості робочих продуктів і документів з ПС тощо;
- — верифікації і валідації, які проводять кваліфікаційне тестування компонентів ПС або продукту на правильність,
- — координування планів робіт з менеджером проекту з вимог до ПС, перевірку виконання вимог (валідація) та тестового середовища;
- — керівника проекту, яка відповідає за фінансові і технічні ресурси проекту, виконання проектних угод замовника та визначеного середовища для розроблення складових проекту;
- — менеджера проекту, відповідального за розроблення проекту на основі вимог, проектних рішень і планів робіт на проекті і їхньої реалізації;
- — проектувальників і програмістів, які відповідають за розроблення проектних рішень і їхню реалізацію у вигляді програм, документів і інших вихідних результатів;
- — керівника конфігурацією, який реєструє версії проекту, зберігає тверді копії й версії на магнітних носіях і розмежовує доступ до них.
Серед цих груп найголовнішим є менеджер проекту, він несе відповідальність перед виконавцями проекту і замовником за успішне розроблення проекту. У його функції входять:
- — розроблення моделі ЖЦ і погодження її з керівником проекту системи;
- — підключення до проекту фахівців розглянутих груп;
- — координація всіх груп програмного проекту між собою;
- — визначення стратегії дій в різних точках процесу ЖЦ з продовження роботи або її закінчення;
- — розроблення основних документів проекту і керування верифікацією функцій на процесах ЖЦ і валідацією продукту на відповідність вимог замовника.
Відповідальний програміст працює в тісній взаємодії з проектувальником для погодження з ним постановок задач і прийняття основних проектних рішень з реалізації функцій проекту. Крім того, він розподіляє роботу між програмістами, контролює дотримання ними порядку розроблення з моделі ЖЦ і стандартів зовнішнього інтерфейс та оброблення помилок тощо.
Розподіл робіт і ролей у проекті. Найчастіше визначення ролей виконавців проекту відповідає моделі ЖЦ. Склад і кількість співробітників, що входять у групи проекту, залежить від масштабу робіт і досвіду співробітників, які повинні бути настільки кваліфікованими, щоб при розробленні виявляти помилки й неточності в проекті, починаючі з ранніх процесів ЖЦ. З організаційної точці зору менеджер проекту оцінює здібності того чи іншого співробітника під час виконання відповідної роботи з проектування або з тестування системи. Розподіл певного обсягу робіт на частини відповідає розподілу ролей і їхній відповідальності в проекті.
Менеджер підбирає для вдалої організації ведення проекту підбирає стиль ведення проекту, наприклад, стиль фірми IBM, який склався при розробленні проекту всесвітньо відомої ОС IBM-370. У ньому проектування ОС і розроблення її продукту виконував головний програміст і група програмістів.
Важлива роль виконував бібліотекар, який зберігав усі проміжні результати роботи команди (документи, тести, модулі, їхні версії тощо) в бібліотеці проекту. Це надавало можливість усім членам команди сконцентруватися на їхній безпосередній роботі створювати необхідні дані для їхнього зберігання у архіві системи.
Кожен член групи тестувальників спілкувався безпосередньо зі всією командою для підготовки відповідних тестових даних щодо тестування модулів і системи у цілому, а головний програміст сам переглядав частини основного проекту й програм.
Альтернативна структура ведення проекту описана Вейнбергом (Weinberg), так зване знеособлене програмування, коли всі несуть однакову відповідальність за якість продукту. У проекті не концентруються на персоналіях, критиці піддається програмний продукт, а не члени групи. Така структура підходить для маленьких груп програмістів.
Сьогодні в екстремальному програмуванні пропонується відповідальність кожного учасника процесу розроблення проекту за виконання своєї роботи.
Моделювання робіт у проекті. У військових відомствах розроблено загальну структуру команди для створення інтегрованого продукту (Integrated Product Development Team).
В цьому проекті менеджер керував розподілом обов’язків і встановлював строки для виконання трьох однакових за розміром завдань проекту, що пов’язані з моделюванням робіт у процесах проектування, аналізу й тестування.
Учасники проекту працювали за матричною організацією, за якої кожен інженер входив до складу певного типу робіт (проектування або тестування) в одному або більше частинах проекту. Суть такої організації робіт — у загальних законах дисципліни і робіт для всіх типів груп.
Під час розроблення проекту обов’язки і ролі співробітників постійно змінюються. Це зручно для проекту, у якому часто змінюються плани, для них встановлюються строки в межах тижня або навіть годин. Показником того, якою мірою виконано завдання, є діаграма запланованих і реально виконаних робіт. Часто ця модель обов’язків поєднується з моделлю «з рук у руки» (hand-off). Вона припускає передачу результатів робіт однієї групи для роботи іншій групи.