• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Модель групи FDD

Microsoft Solutions Framework (MSF) Team Model описує підхід Microsoft до організації працюючого над проектом персоналу і його діяльності з ціллю максимізації успішності проекту. Дана модель визначає рольові кластери, їх галузі компетенції і зони відповідальності, а також рекомендації членам проектної групи, які дозволяють їм успішно здійснювати діяльність по втіленню проекту в життя.

Рис. 3.2. Модель групи DSDM

Чемпіон проекту (Project Champion або Executive Sponsor) володіє можливостями і обов’язками по розпорядженню ресурсами і фондами, які необхідні даному проекту. Він несе відповідальність за прийняття будь – яких рішень, пов’язаних з проектом. Ця роль передбачає можливість часткової зайнятості.

Лідер команди (Team Leader) керує командою розробників і забезпечує ефективність її роботи.

Технічний координатор (Technical Coordinator) відповідає за роботу архітектури проекту. Технічний координатор, також, відповідає за загальний технічний стан проекту.

Розробник (Developer) приймає участь в аналізі вимог, моделюванні, проектуванні, основним обов’язком розробника є програмування.

Тестувальник (Tester) відповідає за технічне тестування продукту.

Представницький користувач (Ambassador User) представляє користувачів продукту. Представницький користувач відповідає за те, щоби розробники вчасно отримували зворотній зв'язок зі сторони користувачів.

Користувач – консультант (Advisor User) може бути будь – який користувач, представляючий значну точку зору за продукт. Користувач – консультант вносить в проект знання з певного аспекту використання розроблювального продукту. Ця роль передбачає можливість часткової зайнятості.

Секретар (Scribe) відповідає за протоколювання всіх угод та рішень, прийнятих за час семінарів.

Посередник (Facilitator) відповідає за проведення семінарів. Посередник, також відповідає за ефективність комунікації між всіма членами команди.

Модель проектної групиMSF.

Ефективність використання моделі групиMSF базується на наступних принципах організації команди соратників:

- спрямованість на кінцевий результат;

- установлення на відсутність дефектів;

- прагнення до самовдосконалення;

- зацікавленість в результаті.

Модель групиMSF заснована на постулаті про шість якісних цілей, досягнення яких визначає успішність проекту. Ці цілі визначають модель проектної групи, яка приведена на рисунку 3.3.

Рис.3.3 Модель групиMSF

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

Таблиця 2. Відповідальності рольових кластерів

Переваги моделі групи MSF:

- висока продуктивність;

- відносно легка масштабність;

- висока мотивація праці і зацікавленість всіх членів групи кінцевим успіхом.

Недоліки моделі MSF:

- для формування команди потрібні спеціалісти, рівної кваліфікації і однакової зацікавленості в успіху проекту;

- важливе значення має комунікабельність і вміння працювати в колективі;

- демократична модель команди MSF погано поєднується з жорсткою ієрархічною структурою підприємства [19].

Функціонально – орієнтована розробка ПЗ FDD передбачає наявність шести основних ролей, але кожен учасник проекту може виконати одну або декілька ролей.

Менеджер проекту (Project Manager) є адміністративним лідером проекту і відповідає за управління бюджетом проекту і розподіл ресурсів. На плечах менеджера проекту також лежить подання звітів про стан проекту керівництву організації.

Головний архітектор (Chief Architect) відповідає за загальний дизайн системи. Під час колективних сесій присвячених проектуванню системи, головний архітектор виступає в ролі експерта і посередника. Також головному архітектору належить виключне право прийняття рішень в суперечливих ситуаціях.

Менеджер розробки (Development Manager) відповідає за управління процесом розробки. Обов’язком менеджера розробки є забезпечення ефективного використання всіх ресурсів проекту. Частково, менеджер розробки виступає в ролі арбітра в організаційних суперечках між головними програмістами (наприклад, суперечки про розподіл ресурсів проекту між функціональними командами).

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

Власником класу (Class Owners) є розробник, який відповідає за проектування і реалізацію конкретного класу. В технології розробки ПЗ FDD не використовується поширена практика колективного володіння кодом. При реалізації функціональних можливостей, які порушують декілька класів, відповідні власники класів об’єднуються в функціональні команди і працюють під керівництвом провідного програміста.

Експерти в предметній галузі (Domain Experts) повинні володіти глибоким знанням предметної галузі. Експерти грають роль основних джерел детальної інформації про всі аспекти предметної галузі системи. Експерти предметної галузі постійно взаємодіють з іншими учасниками проекту і активно приймають участь в таких процесах як аналіз вимог, проектування і тестування продукту який розробляється [17].

Переваги використання моделі групи FDD:

- дозволяє управляти проектами до 500 осіб;

- залучати до роботи менш кваліфікованих розробників;

- ефективно контролювати процес розробки.

Читайте також:

1. G2G-модель електронного уряду
2. OSI - Базова Еталонна модель взаємодії відкритих систем
3. Абстрактна модель
4. Абстрактна модель
5. Абстрактна модель оптимального планування виробництва
6. Алгоритми групи KWE
7. Американська модель соціальної відповідальності
8. Англійський економіст У. Бріджез пропонує модель організаційних змін за такими напрямками.
9. Англо-американська модель
10. Англо-американська модель
11. Багатомірна лінійна модель регресії.
12. Багатосегментна модель

Переглядів: 759