Моделі розробки програмного забезпечення. Методологія OpenUp.
6. OpenUP. OpenUp – це ітеративно-інкрементний метод розробки ПЗ. Він позиціонується як легкий і гнучкий варіант RUP.
В основу OpenUP покладені наступні основні принципи:
Колективні робота з метою узгодження інтересів і досягнення загального розуміння;
Розвиток з метою неперервного забезпечення зворотного зв‘язку і вдосконалення проекту;
Концентрація на архітектурних питаннях на ранніх стадіях для мінімізації ризиків і організації розробки;
Вирівнювання конкурентних переваг для максимізації споживацької цінності для зацікавлених осіб.
OpenUP ділить життєвий цикл проекту на чотири фази: початкова фаза, фази уточнення, конструювання та передачі. Життєвий цикл проекту забезпечує надання зацікавленим особам і членам колективу точок ознайомлення та прийняття рішень на протязі всього проекту. Це дозволяє ефективно контролювати ситуацію і вчасно приймати рішення про прийнятність результатів. План проекту визначає життєвий цикл, а кінцевим результатом є розроблений додаток.
OpenUP ділить проект на ітерації: плановані, обмежені в часі інтервали, термін яких звичайно вимірюється тижнями. План ітерації визначає, що саме має бути здано по закінченні ітерації, а результатом є працездатна версія. Колективи розробників OpenUP будуються за принципом самоорганізації, розв‘язуючи питання виконання задач ітерацій та передачі результатів. Для цього вони спочатку визначають, а потім розв‘язують добре деталізовані задачі зі списку елементів робіт.
Базовий процес OpenUP є незалежним від інструментів, малорегламентованим процесом, який може бути розширений для задоволення потреб широкого діапазону типів проектів.
Моделі розробки програмного забезпечення. Методології Microsoft Solutions Framework (msf), етапи управління великими програмними проектами.
4. MSF. Microsoft Solutions Framework – концепція розробки ПЗ від компанії Microsoft. MSF пропонує методики для планування, проектування, розробки і впровадження IT-рішень. MSF має високу гнучкість, масштабованість, відсутність жорстких інструкцій та здатен задовольняти потреби організацій чи проектної групи будь-якого розміру. Команда складається з ролей, кожна з яких орієнтована на досягнення визначених цілей:
Управління продуктом
Управління програмою
Розробка
Тестування
Задоволення потреб замовника
Управління випуском
Вони відповідальні за різні області компетенції та пов‘язані з ними цілі й задачі.
Суть концепції – побудувати основу виробничих відносин та пов‘язану з нею модель команди такими, щоб вони були пристосовуваними для задоволення потреб будь-якого проекту.
Одна роль може бути представлена одним чи кількома співробітниками, в залежності від розміру проекту, його складності та професіональних навичок, що вимагаються для реалізації всіх областей компетенції команди.
Для невеликих команд можливо (і часто необхідно) об‘єднання ролей, але при цьому мають виконуватися наступні умови:
Роль команди розробників не може бути об‘єднана ні з якою іншою роллю.
Уникнення сполучення ролей, що мають зумовлені конфлікти інтересів.
MSF виділяє кілька дисциплін - нетехнологічних областей знань, що важливі для всіх ролей моделі проектної групи MSF (“Біла книга” моделі проектної групи MSF).
На даний момент MSF вміщує три дисципліни:
управління ризиками (risk management),
управління підготовкою (readiness management),
управління проектами (project management).
В рамках цих дисциплін розроблені ефективні практичні методики, що є корисними не тільки у сфері інформаційних технологій, але й у широкому спектрі інших галузей. Часто ці методики застосовують для використання та супроводу IT систем та інших бізнес-процесів у тій же степені, як і до розробки IT проектів. Не створюючи цей інструментарій з нуля, MSF узагальнює знання відповідних дисциплін, що необхідні проектним командам для успішної роботи, і поповнює їх цінним досвідом, що накопичений Micrisoft за минулі роки.
Для забезпечення ефективності роботи кожен з лідерів ролевих кластерів повинен мати адекватний рівень знань кожної з дисциплін MSF.
Що таке управління проектом? Насамперед, незалежно від типу проекту, необхідно розуміти, що ж є суттю управління ним.
Проект (project) – це обмежена часовими рамками діяльність, мета якої полягає у створенні унікального продукту чи послуги. Управління проектами (project management) – це область знань, навичок, інструментарію та прийомів, що використовуються для досягнення цілей проектів у рамках узгоджених параметрів якості, бюджету, термінів та інших обмежень.
У деяких компаніях і країнах під терміном програма (program) розуміють скоординовану групу проектів. Щоб уникнути плутанини з найменуванням ролевого кластеру “Управління програмою” група проектів буде іменуватися портфелем проектів (project portfolio).
MSF виділяє наступні області
відповідальності, навичок та діяльності
з управління проектами:
Прийнятий у MSF підхід до управління проектами має три відмінні характеристики:
Більша частина відповідальності по менеджменту проекту покладається на ролевий кластер “Управління програмою”.
У великих проектах, що використовують масштабовану модель проектної команди, діяльність з управління проектами здійснюється на багатьох рівнях.
Для деяких великих та складних проектів вимагається наявність фахівця чи групи з управління проектами.
Ролевий кластер “Управління програмою” вміщує наступні області компетенції:
“Управління проектом”, “Вироблення архітектурного рішення”, “Контроль виробничого процесу” та “Адміністративні служби”.
Як правило, у невеликих проектах всі ці функції здійснюються одним менеджером програми. Але по мірі росту обсягу і складності проекту у цьому ролевому кластері вирізняються дві гілки спеціалізації: робота над архітектурою / специфікаціями й управління проектом.
Процес розробки по MSF є ітеративним і включає в себе наступні основні фази:
Вироблення концепції
Планування
Розробка
Стабілізація
Впровадження
Модель процесів MSF має весь життєвий цикл створення рішення, в тому числі його впровадження – впритул до моменту, коли рішення починає давати віддачу.
Лідери груп готують для своїх підкоманд плани, які описують ведення робіт, їх моніторинг, управління рамками і змінами, виділення ресурсів, а також координують інформаційні потоки. В цю діяльність вони залучають і всіх інших членів підкоманд. Беручи участь у загальному процесі виявлення ризиків, лідери команд особисто звітують за виявлення ризиків своїх областей компетенції.
Існує три аспекти (з показаних на рисунку з попереднього слайду), відповідальність за які не покладається на лідерів команд:
Управління вартістю проекту зазвичай здійснюється централізовано кластером “Управління програмою”. Розподіл цієї функції серед лідерів команд було б не раціональне й могло б привести до хаосу в роботі.
Функції постачання зазвичай здійснюються ролевими кластерами “Управління програмою” і/чи “Управління випуском” без участі інших лідерів команд. “Управління програмою” керує закупками і укладанням контрактів на надання необхідних для проекту послуг. Наприклад, це може бути залучення до проектної команди у якості субпідрядника сторонньої фірми, що займається web-дизайном. “Управління випуском”, будучи відповідальним за забезпечення роботи проектної групи, здійснює закупівлі апаратного та програмного забезпечення, сприяє покупці іншого майна, що необхідне для команди розробників, лабораторій тестування й створення розроблюваного рішення в цілому.
Управління комунікацією на рівні всього проекту розподіляється серед ролевих кластерів “Управління програмою” і “Управління продуктом”. “Управління продуктом” розробляє комунікаційний план і представляє його на розгляд замовнику та іншим зацікавленим сторонам. “Управління програмою” планує і несе відповідальність за проектні комунікації, такі як звітність про хід проекту, організацію зборів проектної групи та ін. Управління комунікацією також вміщує комунікаційне планування, призначення відповідальних за зовнішні контакти співробітників та надання зацікавленим особам звітів про хід проекту.
Управління програмою. На додаток до відповідальності за високорівневу архітектуру рішення і створення функціональних специфікацій (у відповідності з моделлю проектної групи), ролевий кластер “Управління програмою” є єдиним організатором всіх аспектів діяльності з управління проектом.
“Управління програмою” інтегрує плани підкоманд у зведений план проекту, синхронізує календарні графіки і контролює міжкомандні взаємозв'язки.
Покладання відповідальності за проектування рішення і функціональні специфікації на ту роль, яка відповідальна і за календарний графік та вартість, має суттєву перевагу: це формує баланс між тенденціями до введення у рішення надлишкової функціональності та до урізання бюджету й календарного графіку проекту.
Управління великими й складними проектами. По мірі росту обсягу і складності проекту стає все більш складно управляти його функціональними специфікаціями, підтримувати календарний графік, забезпечувати зовнішню комунікацію, звітність про хід проекту та ін. Для розв'язання цих труднощів часто має сенс розділити обов'язки ролевого кластеру “Управління програмою” на дві групи:
що належить до архітектури рішення;
що належить до управління проектом.
Адміністративні служби проекту
У певному сенсі, великий проект стикається з багатьма потребами, що є і у малих проектах: фінансові контроль, постачання, управління плинністю кадрів, організація консалтингу і навчання, створення робочого середовища і ін. У ще більших проектах задачі моніторингу ходу проекту, вартості й календарного графіку стають дуже часоємними. Щоб дати можливість менеджерам проекту сфокусуватися на самих важливих питаннях, рутинна робота по управлінню проектом переноситься в адміністративні служби (служби підтримки проекту). Вони також допомагають лідерам команд контролювати календарний графік роботи і здійснювати іншу діяльність, пов'язану з управлінням проектом.
Звітність перед замовником
Як правило, замовники хочуть мати єдине джерело відповідальності про хід роботи над проектом. В деяких організаціях цей обов'язок покладається на менеджерів проекту. Такий підхід іноді виправдовує себе у великих і складних проектах, але він може призвести до дисбалансу звітності серед ролевих кластерів, що приведе до зниження ефективності роботи. MSF приймає до уваги потребу замовника у єдиному авторитетному джерелі інформації, але при цьому зберігає баланс відповідальності в середині проектної команди.
В команді, побудованій у відповідності з принципами MSF, кожен ролевий кластер здійснює внутрішню звітність про свою діяльність. На додаток до цього, співробітники кожної з ролей зазвичай підзвітні деякій організаційній структурі поза рамками проектної команди. Оскільки MSF допускає наявність членів проектної групи, що працюють на різні компанії та організації, ієрархії підзвітності можуть вести у будь-якій організації, групи чи департаменти, до яких належать задіяні у проекті особи.
Варто пам'ятати що:
У розглянутому питанні не існує абсолютних рішень. Крім самої проектної групи істотну роль грають структури залучених до проекту організацій та особливості існуючих між ними (договірних) відносин.
Необхідно виявити схеми підзвітності у проекті. Проясніть, хто саме і за які аспекти проекту підзвітний, як у проектній групі, так і поза нею.
Модель проектної групи MSF передбачає наступну відповідальність перед замовником:
Ролевий кластер “Управління продуктом” підтримує зв’язок з замовником і представляє його інтереси у проектній групі. Ця роль служить цілям задоволення замовника.
Задача ролевого кластера “Управління програмою” – успішна поставка рішення у рамках проектних обмежень.
Ролеві кластери “Управління продуктом” та “Управління програмою” разом працюють над задоволенням потреб замовника у рамках проектних обмежень. Вони мають загальну відповідальність за успіх проекту, але добиваються при цьому різних цілей.
Як тільки виникає проблема, яку “Управління продуктом” та “Управління програмою” не здатні розв'язати разом, проводиться ескалація по єдиній проектній ієрархії підзвітності.