- •Технологія програмування та створення програмних продуктів
- •(частина 2)
- •Візуальне моделювання на основі UML
- •MSF – Модель проектної групи (v. 3.1)
- •Анотація
- •1. Основи моделі проектної групи MSF
- •Основні принципи
- •Розподіл відповідальності при фіксації звітності
- •Наділення членів команди повноваженнями
- •Концентрація на бізнес-пріоритетах
- •Єдине бачення проекту
- •Прояв гнучкості і готовність до змін
- •Заохочення вільного спілкування
- •2. Ключові концепції
- •Команда соратників
- •Фокусування на потребах замовника
- •Націленість на кінцевий результат
- •Установка на відсутність дефектів
- •Прагнення до самовдосконалення
- •Зацікавлені команди працюють ефективно
- •3. Випробувані методики
- •Малі багатопрофільні проектні групи
- •Колективна робота
- •Загальна участь в проектуванні
- •4. Огляд моделі команди MSF
- •Задоволені замовники
- •Досягнення результату в рамках проектних обмежень
- •Створення продукту відповідно до специфікації
- •Схвалення випуску продукту лише після того, як всі дефекти виявлені і відлагоджені
- •Підвищення споживчої цінності продукту
- •Безпроблемне впровадження і супровід продукту
- •Ролеві кластери моделі проектної групи
- •I. Ролевий кластер "Управління продуктом"
- •Області компетенції
- •1. Планування продукту
- •2. Бізнес-віддача
- •3. Представлення інтересів замовника
- •4. Маркетинг
- •II. Ролевий кластер "Управління програмою"
- •Області компетенції
- •1. Управління проектом
- •2. Вироблення архітектури рішення
- •3. Контроль виробничого процесу
- •4. Адміністративні служби
- •III. Ролевий кластер "Розробка"
- •Області компетенції
- •1. Технологічне консультування
- •2. Проектування і здійснення реалізації
- •3. Розробка програмних рішень
- •4. Розробка інфраструктури
- •IV. Ролевий кластер "Тестування"
- •Області компетенцій
- •1. Планування тестів
- •2. Розробка тестів
- •3. Звітність про тести
- •V. Ролевий кластер "Задоволення споживача"_
- •Області компетенцій
- •1. Загальнодоступність
- •2. Інтернаціоналізація
- •3. Забезпечення технічної підтримки
- •4. Навчання користувачів
- •5. Зручність експлуатації (ергономіка)
- •6. Графічний дизайн
- •VI. Ролевий кластер "Управління випуском"
- •Області компетенції
- •1. Управління випуском
- •2. Інфраструктура
- •3. Супровід
- •4. Бізнес-процеси
- •Масштабування моделі проектної групи
- •Групи напрямів
- •Функціональні групи
- •Об'єднання ролей
- •Ескалація і підзвітність
- •Модель проектної групи немає організаційної структури
- •Зовнішня координація – на кому лежить відповідальність?
- •Висновок
- •MSF: Модель процесів
- •Анотація
- •Короткий огляд методології
- •Введення
- •Інші моделі процесів
- •Краще з двох світів
- •Базові принципи MSF
- •Єдине бачення проекту
- •Проявляйте гнучкість – будьте готові до змін
- •Концентруйтеся на бізнес - пріоритетах
- •Заохочуйте вільне спілкування
- •Ключові концепції моделі процесів MSF
- •Замовники
- •Зацікавлені сторони (учасники)
- •Що є рішення?
- •Створення базових версій
- •Рамки проекту
- •Управління компромісами
- •Трикутник компромісів
- •Матриця компромісів проекту
- •Характеристики моделі процесів MSF
- •Підхід, заснований на віхах
- •Характеристики підходу, заснованого на віхах
- •Головні і проміжні віхи
- •Віхи як точки синхронізації
- •Віхи як орієнтири виробничої відповідальності
- •Провідні ролі різних фаз
- •Аналіз пройдених віх
- •Ітеративний підхід
- •Характеристики ітеративного підходу
- •Випуск версій
- •Створення "живої" документації
- •Ранні базові версії, відкладені підсумкові версії
- •Щоденні білди
- •Управління конфігураціями проекту
- •Рекомендації для випуску версій рішення
- •Створюючи плани, передбачайте версіонування
- •Перш за все, поставляйте базову функціональність
- •Вибирайте пріоритети, враховуючи ризики
- •Здійснюйте часті ітерації розробки
- •Інституціюйте процедури контролю змін в проекті
- •Цілісний погляд на розробку і впровадження
- •Переваги інтегрованої моделі процесів
- •Зосередження на потребах підприємства
- •Покращена підтримка розробки веб-приложений
- •Покращена підтримка веб-сервісів
- •Поліпшення взаємодії з командою супроводу
- •Зауваження про використання інтегрованої моделі процесів
- •Тривалість фаз не однакова
- •Діяльність може виходити за межі однієї фази
- •Проекти, обмежені розробкою застосування або впровадженням інфраструктури
- •Фази і віхи моделі процесів MSF
- •Фаза вироблення концепції
- •Введення
- •Віха "Концепція затверджена"
- •Результати
- •Основні завдання проектної групи на фазі вироблення концепції
- •Проміжні віхи, що рекомендуються
- •Ядро проектної групи сформоване
- •Чорновий варіант концепції проекту складений
- •Фаза планування
- •Введення
- •Віха "Плани проекту затверджені"
- •Результати
- •Основні завдання проектної групи на фазі планування
- •Проміжні віхи, що рекомендуються
- •Верифікація технологій
- •Базова версія функціональної специфікації створена
- •Базова версія звідного плану проекту створена
- •Базова версія звідного календарного графіка проекту створена
- •Середовища розробки і тестування розгорнені
- •Фаза розробки
- •Введення
- •Віха "Розробка завершена"
- •Результати
- •Основні завдання проектної групи на фазі розробки
- •Проміжні віхи, що рекомендуються
- •Концепція підтверджена
- •Білд n завершений, білд n+1 завершений...
- •Фаза стабілізації
- •Введення
- •Віха "Готовність рішення затверджена"
- •Результати
- •Основні завдання проектної групи на фазі стабілізації
- •Проміжні віхи, що рекомендуються
- •Точка конвергенції
- •Точка досягнення нуля
- •Версії-кандидати
- •Контрольне тестування завершене
- •Тестування прийнятності для споживачів завершене
- •Пілотне впровадження завершене
- •Фаза впровадження
- •Введення
- •Віха "Впровадження завершене"
- •Результати
- •Основні завдання проектної групи на фазі впровадження
- •Проміжні віхи, що рекомендуються
- •Ключові компоненти розгорнені
- •Впровадження на місцях завершене
- •Упроваджене рішення стабілізоване
- •Методики моделі процесів MSF, що рекомендуються
- •Стимулювання винахідливості для розширення функціональності й обмеження ресурсів
- •Фіксування календарного графіка
- •Календарне планування на невизначене майбутнє
- •Використання паралельно працюючих компактних команд
- •Розбиття великих проектів на реальні частини
- •Отримання уроків з пройдених віх
- •Використання прототипіювання
- •Використання частих білдів і швидких тестів
- •Часті ітерації розробки і впровадження
- •Уникання розповзання рамок проекту
- •Оцінка з низу до верху
- •Інтеграція представлених проектною групою оцінок
- •Застосування A
- •Зміни в порівнянні з попередньою версією MSF
- •Висновок
- •Література
- •Анотація
- •Введення
- •Основні відомості про ризики
- •Базові принципи:
- •1. Гнучкість і постійна готовність до змін
- •2. Вільне спілкування
- •3. Отримання зі всього уроків
- •4. Розподіл відповідальності при фіксації звітності
- •Ключові концепції:
- •Найбільш ефективним є превентивне управління ризиками
- •2. Заохочення до виявлення ризиків
- •3. Постійна оцінка ризиків
- •4. Підтримка відкритого спілкування
- •5. Постійний аналіз ризиків
- •6. Кількість ризиків не характеризує реальне положення речей
- •Планування управління ризиками
- •Процес управління ризиками
- •Загальне уявлення
- •Етап 1. Виявлення ризиків
- •Введення
- •Початкові дані
- •Кроки по виявленню ризиків
- •Структурований підхід
- •Класифікація ризиків
- •Формулювання ризиків
- •Результати
- •Етап 1. Аналіз і пріоритезація ризиків
- •Введення
- •Мета
- •Початкові дані
- •Процес аналізу ризиків
- •Вірогідність ризику
- •Загроза ризику
- •Очікувана величина ризику
- •Додаткові кількісні методики
- •Результати
- •Головна таблиця ризиків
- •Інші методи проведення аналізу
- •Документ опису ризиків
- •Список головних ризиків
- •Деактивація ризиків
- •Планування ризиків_
- •Введення
- •Початкові дані
- •Заходи
- •Дослідження
- •Ухвалення
- •Уникнення
- •Перенесення
- •Запобігання
- •Пом'якшення наслідків (реагування)
- •Календарне планування
- •Результати
- •Діяльність по управлінню ризиками
- •Документування планів
- •Оновлення плану і календарного графіка проекту
- •Моніторинг ризиків_
- •Початкові дані
- •Заходи щодо моніторингу
- •Звітність про стан ризиків
- •Результати
- •Коректування ситуації_
- •Мета
- •Початкові дані
- •Дії з коректування ситуації
- •Результати
- •Витягання уроків з ризиків
- •Введення
- •Типи отримуваних уроків
- •Управління витяганням уроків
- •Контекстна класифікація ризиків
- •База знань про ризики
- •Досягнення зрілості в управлінні знаннями про ризики
- •Управління ризиками як складова частина життєвого циклу проекту_
- •Управління ризиками на підприємстві
- •Створення культури управління ризиками
- •Управління портфелем проектів_
- •Висновок
- •MSF: Дисципліна управління проектами
- •Анотація
- •Введення
- •Базові принципи MSF
- •Пр.1: Розподіл відповідальності при фіксації звітності
- •Пр.2: Наділення членів команди повноваженнями
- •Ключові концепції
- •1) Дисципліни MSF
- •2) Поняття управління проектом
- •3) Менеджмент проекту і менеджер проекту
- •4) Управління проектами і специфічні IT-процеси
- •Особливості управління проектами в MSF
- •Роль менеджера проекту покладається на кластер "Управління програмою"
- •Взаємодія "Управління програмою" з лідерами командних ролей
- •A. Функціональні групи
- •B. Групи напрямів
- •Масштабування функцій управління проектом
- •Обов'язки по управлінню проектами
- •Лідери груп
- •Кластер "Управління програмою"
- •Управління великими і складними проектами
- •Адміністративні служби проекту
- •Звітність перед замовником
- •Рекомендації проектним групам
- •Управління рамками проекту
- •Визначення рамок на етапі вироблення концепції
- •Рамки рішення і рамки проекту
- •Визначення рамок (scope definition)
- •Управління змінами рамок (scope change control)
- •Підготовка планів
- •Повторне використання документів
- •Плани проекту
- •Ієрархічна структура робіт
- •Відповідність між WBS, функц. специфікаціями і зведеним планом
- •Створення WBS
- •Рекомендації по декомпозиції роботи
- •Оцінка знизу вгору
- •Інтеграція представлених проектною групою оцінок
- •Формування реалістичних очікувань
- •Невизначеність і точність оцінок
- •Оцінюйте завдання нижнього рівня декомпозиції
- •Аналіз PERT
- •Рекомендації по складанню календарного графіка
- •1) Впорядкування завдань
- •2) Обмеження часу
- •3) Вибір пріоритетів, з врахуванням ризиків
- •Створення часових буферів
- •Висновок
- •MSF: Дисципліна "Управління підготовкою"
- •Анотація
- •Вступ
- •Базові принципи
- •Пр.1: Заохочення вільного спілкування
- •Пр.2: Інвестування в якість
- •Пр.2: Отримання уроків
- •Пр.3: Гнучкість та готовність до змін
- •Ключові концепції
- •1) Інвентаризація наявних знань
- •2) Прагнення до самовдосконалення
- •3) Підготовка повинна бути перманентним процесом
- •Випробувані методики
- •1) Планування підготовки
- •Оцінка і моніторинг професійного рівня і індивідуальних цілей
- •Відноситеся до пропусків в підготовці як до ризиків
- •Огляд процесу Управління підготовкою
- •1) Визначення:
- •2) Оцінювання:
- •3) Коригування:
- •4) Осмислення:
- •Превентивне Управління підготовкою
- •Підготовка впродовж життєвого циклу ІТ
- •Кроки процесу Управління підготовкою
- •Крок 1: Визначення
- •Скл. 1: Проектні сценарії
- •Скл. 2: Кваліфікаційні вимоги
- •Скл. 3: Професійні навики
- •Крок 2: Оцінювання
- •Оцінка знань, умінь, здібностей
- •Специфікація процесу оцінювання
- •Збір і обробка даних
- •Обробка результатів оцінювання
- •Аналіз невідповідностей
- •Створення планів навчання
- •Крок 3: Коригування
- •Навчання
- •Моніторинг прогресу
- •Крок 4: Осмислення
- •Аналіз результатів
- •Управління знаннями
- •Вимоги до професійних навиків проектних ролей
- •Створення планів підготовки
- •Висновок
Віха "Готовність рішення затверджена"
До моменту настання цієї віхи проектна група завершує дозвіл всіх істотних проблем і проводиться випуск або впровадження рішення. Відповідальність за безперервне управління і підтримку рішення формально переходить від проектної групи до команд супроводу.
Результати
Результатами фази стабілізації є:
•Остаточний продукт (golden release).
•Документація випуску (release notes).
•Матеріали підтримки рішення.
•Результати і інструментарій тестування.
•Початковий і здійснимий код застосувань.
•Проектна документація.
•Аналіз пройденої фази (milestone review).
Основні завдання проектної групи на фазі стабілізації
Наступна таблиця описує основні завдання і сфери відповідальності кожного з ролевих кластерів проектної групи під час фази стабілізації.
Ролевий кластер |
|
Фокус |
|
|
Управління продуктом |
Виконання комунікаційного плану; планування прем'єри |
|||
|
продукту. |
|
|
|
Управління програмою |
Моніторинг проекту; пріоритезація помилок. |
|
||
Розробка |
Усунення помилок; оптимізація програмної коди. |
|||
Задоволення споживача |
Доопрацювання експлуатаційного керівництва; учбові |
|||
|
матеріали. |
|
|
|
|
|
|||
Тестування |
Тестування; повідомлення про помилки і їх статус; |
|||
|
тестування конфігурації. |
|
|
|
Управління випуском |
Розгортання і підтримка пілотного впровадження; |
|||
|
планування |
впровадження; |
навчання |
персоналу |
|
супроводу. |
|
|
|
|
|
|
|
|
Проміжні віхи, що рекомендуються
Точка конвергенції
У точці конвергенції (bug convergence) стає помітний істотний прогрес в усуненні помилок, тобто швидкість усунення помилок починає перевершувати швидкість їх виявлення. Рис. 10 ілюструє суть точки конвергенції.
Оскільки кількість знайдених, але не усунених помилок може коливатися навіть після того, як воно почало убувати, конвергенція може розглядатися швидше як тенденція, ніж як фіксований момент в часі. Услід за цією віхою кількість активних помилок повинна продовжувати убувати, аж до точки досягнення нуля. Точка конвергенції дає проектній групі можливість зрозуміти, що процес тестування наближається до кінця.
69
Рисунок 14. Точка конвергенції
Точка досягнення нуля
Точка досягнення нуля (zero-bug bounce) – це момент, коли вперше всі виявлені помилки виявляються усуненими. Рис. 11 ілюструє цю крапку. Услід за нею списи кількості активних помилок повинні ставати все менше, аж до повного згасання в мить, коли рішення вже достатньо стабільно для випуску першої версії - кандидата.
Істотну роль грає ретельна пріоритезація помилок, оскільки усунення всякою з них містить ризик внесення нових помилок. Точка досягнення нуля ясно показує, що проектна група наближається до створення стабільної версії-кандидата (release candidate).
Відмітимо, що нові помилки після досягнення цієї віхи напевно будуть знайдені. Проте точка досягнення нуля – це перший момент в роботі над проектом, коли команда може чесно відзвітувати про відсутність активних помилок і сфокусуватися на збереженні цього стану.
Рисунок 15. Точка досягнення нуля
Версії-кандидати
Для пілотної групи готується і випускається серія версій-кандидатів. Випуск кожною
зних є проміжною віхою. Ці версії мають наступні особливості:
•Кожна версія-кандидат має повний набір складових, необхідних для впровадження рішення у виробництво.
•Створення версії-кандидата служить тестом готовності рішення до випуску, тобто перевіряє готовність всіх його складових.
70
•Період тестування, наступний за створенням кожної версії-кандидата, визначає, чи придатна створена версія до впровадження, або ж проектна група повинна підготувати нову версію-кандидат, що виправляє недоліки попередньої.
•Тестування версій-кандидатів, що проходить усередині проектної групи, вимагає високого ступеня концентрації і інтенсивності роботи і фокусується на виявленні критичних "накладок" (showstopper bugs).
•Тестування зв'язане з процесом пріоритезації всіх ново-виявлених помилок, необхідним для організації їх усунення.
•Маловірогідно, що перша версія-кандидат виявиться завершальною. Як правило, при інтенсивному тестуванні версій-кандидатів будуть виявлені "накладки".
Контрольне тестування завершене
Суть цієї проміжної віхи полягає в підготовці до пілотного випуску рішення. Дана віха дуже важлива, оскільки наступає момент, коли рішення "зіткнеться" з виробничим середовищем, і проектна група винна якомога ретельніше відтестувати рішення до цього моменту, – до початку випробування пілотного випуску.
До віхи "Контрольне тестування завершене" (pre-production test complete) проектна група винна:
•Оцінити результати тестування відповідно до наявних критеріїв успішності.
•Підготувати середовище впровадження.
•Створити необхідні для впровадження процедури, скрипти і масиви даних (load sets).
•Мати готові учбові матеріали.
•Забезпечити умови для супроводу рішення.
•Створити і протестувати план "відкоту" (rollback plan).
Дана віха може вважатися пройденою лише після отримання проектною групою повної упевненості в готовності і відлагодженості всього, що необхідне для впровадження рішення.
Тестування прийнятності для споживачів завершене
Тестування прийнятності для споживачів (user acceptance testing) і дослідження ергономічності (usability studies) проводяться починаючи з фази розробки і продовжуються впродовж фази стабілізації. Їх мета – переконатися в тому, що нова система відповідає вимогам споживачів і бізнесу. Вони не є індикаторами остаточної прийнятності рішення для замовника (customer acceptance), про яку можна говорити лише в самому кінці проекту.
По досягненню даної віхи користувачі здійснюють тестування і схвалюють роботу рішення в невиробничому середовищі (non-production environment). Це включає перевірку інтеграції системи з тими, що працюють у виробничому середовищі бізнес-додатками. Також повинні бути перевірені розроблені процедури "відкоту" і відновлення після збоїв (rollout and backout procedures).
Після схвалення менеджерами випуску, розроблене програмне забезпечення і всі компоненти, що докуповують до нього, переносяться з архіву групи розробки в архів групи супроводу. У MOF він називається бібліотекою завершеного програмного забезпечення (Definitive Software Library - DSL). "Управління випуском" відповідально за компоновку рішення (зібраного з компонент випуску) в середовищі тестування із застосуваннями, зібраними в DSL.
Тестування споживчих якостей дає персоналу супроводу і користувачам можливість зрозуміти і випробувати нову технологію на практиці. Цей процес допомагає виявити
71
аспекти, в яких у користувачів виникають труднощі. Також тестування дозволяє менеджерам випуску виявити проблеми, які можуть перешкодити успішному впровадженню рішення.
Пілотне впровадження завершене
Під час цієї проміжної віхи проектна група тестує рішення цілком в середовищі, максимально наближеному до виробничих умов. У MSF пілотний реліз (pilot release) – це впровадження вирішення в частину виробничого середовища або для частини користувачів. Залежно від проекту, пілотний реліз може приймати різні форми.
•На підприємстві це може бути реліз для групи користувачів або підмножини серверів даних.
•Для веб-сервера-розробки це може бути хостинг на тестових серверах або в підкаталогах, які доступні в Internet тільки через тестовий веб-сервер-адресу.
•Виробники комерційного програмного забезпечення, такі як майкрософт, часто випускають новий програмний продукт для спеціальної групи "першо-випробувачів" до того, як буде створена остаточна його версія.
Загальним для всіх цих форм заздалегідь випуску є максимальне наближення тестування до реальних умов.
Віха "Пілотне впровадження завершене" не може вважатися пройденою, поки проектна група не упевнилася остаточно, що створене рішення життєздатне у виробничому середовищі, і кожна його компоненту готова до впровадження. На додаток до цього повинно бути здійснено наступне:
•Перед випуском пілотної версії її випробувачі і проектна група повинні виробити чіткі критерії успіху пілотного впровадження. Вони повинні відповідати загальним критеріям успіху розробки.
•Всі виявлені проблеми повинні бути улагоджені або доопрацюванням коди, або документуванням обхідних шляхів (work-arounds) для персоналу впровадження і супроводу, або ж включенням відповідного матеріалу в супровідне керівництво і учбові курси.
•До моменту почала роботи пілотної версії повинна бути створена інфраструктура супроводу. Це може зажадати навчання персоналу супроводу. Процедури дозволу проблем пілотній версії можуть сильно відрізнятися від тих, що використовуватимуться під час остаточного впровадження і повноцінної експлуатації рішення.
•Щоб перевірити працездатність процесу впровадження, необхідно провести пробне випробування для кожного з його елементів. Це допоможе завчасно виявити труднощі впровадження.
Як тільки в результаті пілотного впровадження накопичено і проаналізовано достатня кількість даних, проектній групі необхідно ухвалити рішення про подальші дії. Можливі наступні варіанти:
•Крок вперед: пілотне впровадження нового реліза.
•Відкіт назад: виконується план відкоту, і пілотна група повертається до конфігурацій, що існували до пілотного впровадження. Пізніше спроба пілотного впровадження буде повторена знов із стабільнішою версією рішення.
•Припинення: пілотна версія "заморожується".
•Виправлення і продовження: пілотна група отримує "латку" (patch) до існуючого коду.
•Перехід до фази впровадження.
72