Вироблення архітектури рішення
• Організація високо-рівневого проектування рішення.
• Управління функціональною специфікацією.
• Визначення рамок проекту і ключових компромісних рішень.
"Вироблення архітектури рішення" (solution architecture) – це область компетенції
ролевого кластера "Управління програмою", відповідальна за логічний дизайн рішення і опис його функцій. Її основне завдання - забезпечення результативного і ефективного використання продукту споживачем для досягнення своїх цілей.
Зони відповідальності "Вироблення архітектури рішення" включають:
a) Організацію високо-рівневого проектування рішення.
b) Управління функціональною специфікацією.
c) Визначення рамок проекту і ключових компромісних рішень.
Будучи відповідальною за логічний дизайн рішення, "Вироблення архітектури рішення" здійснює життєво важливий зв'язок між бізнес-стороною проекту (що представляється кластером "Управління продуктом" за допомогою концептуального дизайну) і технологічною його стороною (що представляється кластером "Розробка" за допомогою фізичного дизайну). Ця область компетенції "опікає" функціональну специфікацію. Вона прагне до досягнення внутрішньо-командного консенсусу про дизайн і обґрунтовує вибраний підхід перед зацікавленими в проекті сторонами. Дана область компетенції також відповідає за відповідність всіх елементів дизайну початковим вимогам (і,
30
зрештою, забезпечення бізнес-віддачі). Кожен елемент рішення повинен реалізовувати деяку вимогу: таким чином проектна група може оцінити наслідки будь-яких змін дизайну для бізнес-корисності кінцевого продукту.
Заходи, архітектуру рішення", що проводиться "Виробленням, включають:
a) Створення концепції рішення і його узгодження з архітектурою підприємства замовника; розробка стратегії версіонування продукту; вироблення рекомендацій до планів збору вимог.
b) Збір вимог до інтероперабельності (interoperability) рішення, його відповідності корпоративній архітектурі і нормативам, що діють; здійснення логічного проектування; складання "карти" відповідності (traceability map) елементів дизайну початковим вимогам замовника; створення функціональної специфікації; специфікація проміжних версій продукту.
c) Управління змінами функціональній специфікації; підтримка "карти" відповідності; роз'яснення специфікації іншим ролевим кластерам проектної групи і зовнішнім зацікавленим особам; зв'язок з іншими проектними групами для забезпечення інтероперабельності.
d) Участь в процесі пріоритезації; формування очікувань зацікавлених сторін.
e) Зв'язок з архітектурною групою підприємства; коректування вимог до майбутніх версій рішення.
Співробітники, що працюють в даній області компетенції, повинні бути утвореними в технологічному плані і мати великий досвід у поєднанні із здатністю зіставляти технологічні проблеми з потребами бізнесу, що стоять за ними. Хоча архітектори рішення можуть покластися на досвід команди розробників в питаннях специфічних технологій, вони винні дуже чітко усвідомлювати наслідки тих або інших технічних кроків і розуміти їх взаємозв'язок і їх вплив на середовище впровадження. Також архітектори рішення повинні бути в змозі обговорити вищезазначені наслідки з архітекторами замовника і негайно вирішити будь-які конфлікти між пропонованим рішенням і архітектурою підприємства замовника.
Контроль виробничого процесу
• Організація контролю виробничого процесу.
• Вироблення рекомендацій по його вдосконаленню.
Область компетенції "Контроль виробничого процесу" (process assurance) ролевого
кластера "Управління програмою" забезпечує контроль за проходженням проектною групою виробничим процесам, націленим на досягнення високоякісного результату. При цьому основна увага приділяється виявленню і усуненню першопричин дефектів. "Контроль виробничого процесу" має дві основні зони відповідальності:
a) Визначення ключових виробничих процесів, використовуваних командою при роботі над проектом, і консультування команди по питаннях їх впровадження.
b) Проведення аналізу ефективності процесів, вироблення рекомендацій по їх вдосконаленню, моніторинг їх реалізації і адекватності.
c) Ця область компетенції здійснює наступну діяльність:
d) Розробка внутрішньо проектних виробничих протоколів і процесів.
e) Консультування по питаннях ефективного використання виробничих процесів; контроль реалізації процесів; визначення їх адекватності; вироблення рекомендацій по вдосконаленню процесів.
Співробітники, що працюють в даній області компетенції , повинні мати певну незалежність від проектної групи, можливість поглянути на проект " с сторони". Часто вони навіть підзвітні особі, що не входить безпосередньо до проектної групи.
31
Адміністративні служби
• Організація процесів управління проектом і допомога лідерам команд (team leads) в їх використанні.
• Організація ряду адміністративних служб, необхідних для підтримки ефективної роботи команди.
Ця область компетенції ролевого кластера "Управління програмою" відповідальна за
реалізацію процесів по управлінню проектом і за адміністративну підтримку проектної групи.
Вона забезпечує реалізацію проектною групою процесів, що відповідають специфікації дизайну . Адміністративні служби (administrative services) створюють умови, при яких проектна команда може працювати ефективно, випробовуючи мінімум бюрократичних перешкод.
Відповідальність адміністративних служб включає:
a) Реалізацію процесів управління проектами і допомогу лідерам груп в їх використанні. Наприклад, збір необхідної для звітності інформації, допомога лідерам груп в складанні звітів і управлінні планом і календарним графіком проекту.
b) Забезпечення ряду адміністративних послуг, необхідних для підтримки ефективної роботи команди, таких як складання розкладу зборів, постачання і складання контрактів.
Адміністрація проекту здійснює:
a) Забезпечення стартових процесів проекту, таких як залучення співробітників з інших організацій, підготовка контрактів, забезпечення інфраструктури проектної групи (робочі місця, телефони, контроль безпеки і так далі)
b) Узгодження правил планування; допомога лідерам груп у виробленні планів і календарних графіків; збір інформації, необхідної для створення звідного плану і календарного графіка проекту; організацію процесів звітності про хід здійснення проекту і про фінансовий стан.
c) Допомога лідерам груп в складанні звітності про хід проекту, формування звідних проектних звітів.
d) Забезпечення згортання всіх адміністративних систем по закінченню проекту.
e) Організацію загальної діяльності по адмініструванню проекту (планування зборів, управління ризиками і проблемами, підтримка таблиці головних рисок, списку планових заходів і так далі); складання звітів про хід проекту і фінансових звітів; організація суміжних робочих місць членів команди з метою об'єднання колективу.
Компетенція адміністратора проекту вимагає поєднання хороших адміністративних здібностей з уважним відношенням до деталей за наявності істотного досвіду в методиках планування проектів і чіткого розуміння корпоративних правил і інструкцій організацій-постачальників. У крупних проектах для новачків є прекрасна можливість роботи в рамках адміністративних служб в цілях набуття досвіду, необхідного для подальших проектів.
III. Ролевий кластер "Розробка"
Першорядним завданням ролевого кластера "Розробка" є побудова рішення відповідно до специфікації. Її виконання означає створення рішення, відповідно очікуванням замовника і умовам, сформульованим в функціональній специфікації. Також даний ролевий кластер строго слідує виробленій архітектурі і дизайну рішення, які спільно з функціональною специфікацією складають зведений опис кінцевого продукту.
На додаток до функції безпосередньої розробки програмного рішення на даний ролевий кластер покладаються обов'язки по технологічному консультуванню проектної групи. У цій якості розробники займаються підготовкою початкових даних для проектування
32
і вибору технологічного інструментарію рішення. Також ролевий кластер "Розробка" створює функціональні прототипи для перевірки правильності ухвалених рішень і зменшення ризику.
Як творці програмного рішення, розробники здійснюють низькорівневе проектування самої програми і її елементів, оцінюють трудовитрати на реалізацію, а потім здійснюють побудову самого програмного рішення. Розробники самі оцінюють власні витрати і відстежують розклад, оскільки їх повсякденна діяльність зв'язана з різними нештатними ситуаціями. Ця концепція називається оцінюванням від низу до верху (bottom-up estimation) і є фундаментальною частиною філософії MSF. Мета даної концепції полягає в досягненні більшої обґрунтованості календарного плану і збільшенні відчуття відповідальності тих, хто визначає терміни цього плану, і від чиєї продуктивності залежить його виконання.
Ролевий кластер "Розробка" містить в собі наступні області компетенції:
1. Технологічне консультування,
2. Проектування і здійснення реалізації,
3. Розробка програмних рішень,
4. Розробка інфраструктури.
Області компетенції
Технологічне консультування
• Виконання функцій технологічних консультантів.
• Оцінювання і верифікація технологій.
• Активна участь в створенні і обговоренні функціональної специфікації.
• Внесок в створення корпоративних стандартів розробки програмного забезпечення. Область компетенції "Технологічне консультування" (technology consulting) служить
ресурсом дозволу технічних проблем. Виконуючи роль технологічних консультантів, розробники повинні надавати необхідну інформацію для проектування, оцінки і верифікації технологій; проводити попередні дослідження з метою мінімізації рисок.
На фазі вироблення концепції дана область компетенції аналізує вимоги замовників і споживачів з погляду тієї, що їх реалізовується. "Технологічне консультування" вносить свій внесок в підготовку документа загального опису проекту, оцінюючи технічні проблеми, що впливають на можливість реалізації проекту при заданих параметрах. "Технологічне консультування" зважує все "за і проти" кожного підходу до реалізації і визначає адекватність спочатку вибраних технологічних засобів. В рамках цієї діяльності розробники можуть вести дослідницьку роботу, проводити консультації з іншими сторонами як усередині організації, так і поза нею, вести обговорення з постачальниками технологій. В цілях додаткової верифікації "Технологічне консультування" може розробляти прототипи ("іграшкові" версії рішення з неповною функціональністю), щоб підтвердити з їх допомогою життєздатність аналізованих концепцій. Це особливо важливо в проектах, що вимагають використання нових технологій, або ж в тих наочних областях, де у проектної групи відсутній достатній досвід.
Дата добавления: 2018-05-09; просмотров: 308; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!