10 Пріоритетів RUP, Комерція, Різне, статті

Для того, щоб ефективно застосовувати Rational Unified Process (більш відомий як RUP), важливо спочатку зрозуміти його ключові цілі, чому кожна з них важлива, і як ці цілі взаємодіють один з одним для того, щоб допомогти вашому колективу розробників створити якісний продукт, відповідний запитам споживачів.


Заміська прогулянка? Проект створення ПЗ? Спочатку визначте пріоритети


Якось увечері мій сусід Ренді звернувся до мене за допомогою: він збирався зробити пішу прогулянку на уїкенд і намагався визначити які речі пакувати. Він знає, що я часто керую і беру участь у походах по глухих закутках, і дивувався, як швидко і ефективно я визначаю, переглядаючи список всього необхідного спорядження та одягу, які речі упакувати в обмежений обсяг. Він запитав: “Як ви думаєте – Мені був би корисний цей список? “


“Звичайно, але я боюся, що від цього буде мало толку”. Я пояснив йому: подивіться, у моєму списку похідних речей буквально сотні пунктів для самих різних походів – від туризму і сходження до лижних прогулянок, льодових сходжень і катань на байдарці – і для подорожей тривалістю від простих одноденних прогулянок до багатоденних експедицій. Я знав, що без деякого керівництва Ренді, ймовірно, не зможе пробратися через безліч пунктів в моєму списку і визначити, в чому він дійсно потребує для свого щодо простого пікніка.


Почніть з самого необхідного, потім додайте


Я запропонував переглянути те, що Ренді вже пхнув в свій переповнений тюк. Ми змогли б побачити те, чим можна було б знехтувати, щоб полегшити тягар, і також побачити, не забуті які-небудь необхідні речі. Дуже скоро я міг сказати, що він дійсно не зовсім розумів, що таке “найнеобхідніше” для прогулянки по ненаселеній місцевості. Я взяв чистий аркуш паперу і склав список з десяти пунктів:




    1. Карта
    2. Компас
    3. Сонячні окуляри і сонцезахисний крем
    4. Запасна одяг
    5. Додаткова їжа і питво
    6. Ліхтар
    7. Набір для надання першої допомоги
    8. Зажигалка
    9. Сірники
    10. Ніж

“Дивись, Ренді. Ось список, який тобі потрібен. Якщо ти почнеш з цих десяти першочергових пунктів, тоді інші необхідні речі для будь-якого походу будуть очевидні для тебе”. Я запам’ятав цей список багато років тому, коли почав ходити по горах, і до цих пір використовую його незалежно від того, до якого походу готуюся і наскільки тривалим він буде. Значимість кожного з цих пунктів зростає або зменшується, залежно від походу, але починати з короткого списку, розширюючи його в міру необхідності, набагато простіше, ніж починати з довгого списку і намагатися вирішити, що не потрібно брати.


Застосування цього підходу до RUP


Часто, коли я допомагаю колективу, що працює над проектом, розібратися з багатьма елементами RUP, я чую такі питання: “Як мені розібратися у всіх цих речах і визначити, що дійсно необхідно для мого проекту? “.” RUP містить так багато інформації і призначений тільки для великих проектів. Чи можу я використовувати його для мого невеликого проекту? “


Тоді я вирішив: щось, в чому ці люди дійсно потребують, – це “Десять пріоритетів RUP”, то, що аналогічно простому списку, який я дав моєму другові Ренді і що могло б бути відповідною точкою старту для будь-якого проекту: невеликого, середнього та великого. Цей список підкреслював б те, що я називаю сутністю RUP або іншого ефективного процесу створення ПЗ, що має аналогічні цілі.


Для тих з Вас, хто не знайомий з RUP, ця діаграма являє інкрементний і итерационную природу RUP, який охоплює великий набір дисциплін в життєвому циклі розробки ПЗ, включаючи артефакти, керівництва, ролі членів колективу і види діяльності.


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


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


Десять Пріоритетів RUP


Отже, що має бути у списку “Десять пріоритетів RUP”? Ось мій варіант:




    1. Розробити концепцію
    2. Виробити план
    3. Ідентифікувати і пом’якшувати ризики
    4. Встановлювати і відстежувати проблеми
    5. Проаналізувати прецеденти
    6. Розробити компонентну архітектуру
    7. Інкрементное створювати і тестувати продукт
    8. Перевіряти та оцінювати результати
    9. Управляти змінами та контролювати їх
    10. Забезпечувати підтримку користувачам

Давайте розглянемо кожен з цих пунктів окремо, визначимо, як вони входять в RUP і з’ясуємо, чому кожен із них включено в мій “короткий список”.


1. Розробити концепцію


Наявність ясної концепції – ключ до розробки продукту, який відповідає реальним потребам ваших замовників. Концепція являє собою сутність Requirements Workflow (робочого потоку вимог) в RUP: аналіз проблеми, розуміння потреб замовників, визначення системи, відстеження вимог по мірі їх зміни. Концепція надає високо-рівневу (іноді контрактну) основу для більш докладних технічних вимог. Таким чином, під концепцією мається на увазі чіткий, зазвичай високо-рівневий, погляд на проект створення ПЗ, який може бути ясно сформульований для будь-якого керівника або розробника в процесі виконання проекту. Концепція містить високорівневі вимоги та конструктивні обмеження, надаючи читачеві розуміння принципів розроблюваної системи. Вона також є відправною точкою для процесу затвердження проекту, і тому тісно пов’язана з бізнес-прецедентами. І, нарешті, оскільки концепція містить в собі відповіді на основні питання по проекту, вона є засобом обгрунтування майбутніх рішень.


Зміст концепції має відповісти на такі питання, які також можуть бути розбиті на окремі пункти:



2. Виробити план


“Продукт настільки хороший, наскільки хороший план розробки цього продукту”2


У RUP вся інформація необхідна для управління проектом збирається в план розвитку ПЗ (Software Development Plan (SDP)); SDP може коригувати ряд окремих пунктів, розроблених в початковій фазі. SDP повинен постійно підтримуватися в актуальному стані в процесі виконання проекту.


SDP визначає графік виконання проекту (включаючи Project Plan (План Проекту) і Iteration Plan (План ітерацій)) і потреби в ресурсах (Ресурси та Засоби), і використовується для контролю виконання графіка. Він також керує плануванням для інших компонент процесу: Project Organization (Організація Проекту), Requirements Management Plan (План Управління Вимогами), Configuration Management Plan (План Управління Конфігурацією), Problem Resolution Plan (План Рішення Проблем), QA Plan (План Контролю Якості), Test Plan (План Тестування), Test Cases (Тестування Образцов), Evaluation Plan (План Експертизи), Product Acceptance Plan (План приймання продуктів).


У простому проекті формулювання цих планів можуть складатися тільки з одного або двох пропозицій. Configuration Management Plan, наприклад, може просто зажадати: “В кінці кожного дня заархівувати вміст структури директорій проекту, скопіювати на zip-диск з ярликом, на якому вказати дату і номер версії, і віднести диск в центральне сховище “.


Формат Software Development Plan не так важливий, як та діяльність і міркування, які увійшли до нього. Дувайт Ейзенхауер (Dwight D. Eisenhower) говорив: “План ніщо, планування все”. Пункт “Виробити План “спільно з пріоритетами 3, 4, 5 і 8 зі списку являють собою сутність Project Management Workflow (Потоку робіт управління проектом) в RUP, який включає зародження проекту, оцінку обсягу і ризику, моніторинг проекту, планування і оцінку кожної ітерації і фази.


3. Ідентифікувати і пом’якшувати ризики


Визначити і вжити енергійних заходів проти ризикованих елементів проекту якомога раніше – один із суттєвих принципів RUP. Кожен елемент ризику, визначений колективом розробників, повинен мати відповідний план зменшення ризику. Список таких елементів повинен служити і як інструмент планування діяльності по проекту, і як база для визначення ітерацій.


4. Встановлювати і відстежувати проблеми


Безперервний аналіз об’єктивних даних, одержуваних безпосередньо в результаті поточної діяльності і змінюють конфігурацію продукту важливий для будь-якого проекту. У RUP регулярні оцінки стану забезпечують механізм для адресації, повідомлення та вирішення ділових проблем, технічних проблем і ризиків проекту. Раз відповідна команда визначила перешкоди, вона визначає кожної з цих проблем відповідну дату і людини, відповідальної за її дозвіл. Хід справи повинен регулярно контролюватися, а поновлення повинні виконуватися в міру необхідності.


Ці “відбитки” проекту підкреслюють проблеми, які потребують уваги керівництва. Хоча час між перевірками може змінюватися, регулярні оцінки дозволяють менеджерам бути в курсі розвитку проекту та усувати будь-які зупинки і перешкоди, що заважають руху вперед.


5. Аналіз бізнес-прецеденту


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


6. Розробка компонентної архітектури


У RUP архітектура програмної системи (в даний момент часу) визначається як організація чи структура взаємодії важливих компонентів системи за допомогою інтерфейсів з компонентами, складеними з все більш і більш дрібних компонентів і інтерфейсів. Що є головними частинами? І як вони взаємодіють один з одним?


RUP дає Вам методичне, системне засіб для розробки, розвитку та обгрунтування такої архітектури. Дії, що складають Технологію Аналізу та Конструювання (Analysis and Design Workflow) включають в себе визначення підходящої архітектури, удосконалення архітектури, аналіз її поведінки і розробку компонентів системи.


Щоб говорити і міркувати про архітектуру програмного продукту, ви повинні спочатку створити архітектурне уявлення, яке описує важливі аспекти цієї архітектури. У RUP це здійснюється в Software Architecture Document (SAD), який представляє множинні види архітектури. Кожен вид співвідноситься з інтересами різних учасників процесу розробки: кінцевих користувачів, інженерів, менеджерів, системних інженерів, системних адміністраторів і т.д. SAD дозволяє системним архітекторам та іншим членам команди ефективно взаємодіяти для прийняття проектних рішень, важливих з архітектурної точки зору.


7. Інкрементное створювати і тестувати продукт


Сутність технології потоку робіт Implementation and Test в RUP полягає в инкрементной програмуванні, у створенні та тестуванні компонент системи при здійсненні проекту, в генерації виконуваних версій ПЗ в кінці кожної ітерації.


Архітектурний прототип оцінюється в кінці фази розробки; при необхідності він може включати прототип інтерфейсу користувача. Потім в процесі кожної ітерації фази конструювання, компоненти об’єднуються в виконувані, тестовані конструкції, далі розвиваються до кінцевого продукту. Ключем до цього істотного елементу процесу є постійне управління конфігурацією і огляд діяльності.


8. Перевірка та оцінка результатів


Iteration Assessment (Оцінка ітерації) в RUP в повній відповідності зі своєю назвою містить результати ітерації. Вона визначає, якою мірою ітерація відповідає оцінним критеріям, включаючи накопичений досвід і зміни процесу, які повинні бути здійснені. В залежності від можливостей і ризику проекту, природи ітерації атестація змінюється від простого протоколу про демонстрацію і її результати до повного, офіційного звіту про випробування. Головне тут – звертати увагу на проблеми процесу, так само як на проблеми продукту. Чим раніше Ви відстанете, тим більше часу Вам потрібно для того, щоб надолужити.


9. Управління змінами та контролюй їх


Сутністю Configuration and Change Management Workflow (Технологія Управління Зміною і Конфігурацією) в RUP є управління та контроль обсягу проекту, оскільки зміни відбуваються на всьому протязі проектного циклу. Це робиться для того, щоб розглядати всі запити зацікавлених осіб і задовольняти їх максимально можливо, за умови своєчасного випуску якісного продукту. Як тільки користувачі отримають перший прототип продукту (часто навіть раніше), вони вимагатимуть змін. Важливо, щоб ці зміни пропонувалися і керувалися несуперечливим чином.


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


10. Забезпечуйте підтримку користувачеві


У RUP сутністю Deployment Workflow (Потік робіт розгортання) є поставка готового продукту поряд з будь-якими матеріалами, необхідними для того, щоб допомогти користувачеві вивчити, використовувати і підтримувати продукт. Як мінімум, проект повинен бути забезпечений User “s Guide (Керівництво Користувача) – це можна здійснити через інтерактивну довідку – і, можливо, Installation Guide (Керівництво по Інсталяції) і Release Notes (Примітки по Версії). В залежності від складності продукту, користувачі можуть мати потребу в навчальних матеріалах. І, нарешті, Bill of Materials (специфікація поставки) повинен ясно інформувати, що поставляється разом з продуктом.


Про вимоги


Деякі з вас, розглядаючи мій список пріоритетів, можуть не погодитися з моїм вибором. Ви можете запитати, наприклад, де місце в цій картині для “requirements” (вимог)? Хіба вони не істотні? Я розповім вам, чому я не включив їх до списку. Іноді я запитую у колективу розробників (особливо у колективу, що займається внутрішнім проектом), “Які ваші вимоги?” то отримую відповідь: “У нас дійсно немає жодних вимог”. Перший раз мене це вразило (тому мій попередній досвід був пов’язаний з розробками в аерокосмічній області). Як могли вони не мати ніяких вимог? За міру того, як я працював з цими колективами, я з’ясував, що для них “вимоги” означають ряд прийшли ззовні інструкцій про те, що вони мають отримати, або проект не буде прийнятий, і в цьому сенсі вони не мають жодних вимог! Особливо якщо колектив пов’язаний з дослідженням та розробкою, вимоги до продукту можуть змінюватися протягом усього проекту.


Для таких проектів я ставлю наступне питання: “Добре, тоді яка ваша концепція продукту?”. Тоді в їхніх очах з’являється блиск і ми легко проходимо з усіх питань (позначені маркером) пріоритету # 1 RUP (“Develop a Vision”), і вимоги виникають самі собою.


Для груп, що працюють над контрактами з вказаними вимогами, може бути корисно мати “Зустрічні Вимоги” в їхньому списку пріоритетів. Пам’ятайте, мій список передбачається тільки як відправна точка для подальшого обговорення.


Резюме: Застосування цих Десяти Пріоритетів


Отже, що можуть “Десять Пріоритетів RUP” змінити в моєму житті? Ось декілька варіантів, як ці рекомендації можуть допомогти мені в роботі з проектами різних розмірів.


Для Дуже Маленьких Проектів


Перш за все, якщо хто – то запитує мене, як вони могли б використовувати RUP і засоби розробки Rational для створення простого продукту з дуже маленькою, недосвідченої командою, яка тільки знайомиться з процесом, я можу поділити мій список “10 Пріоритетів” і команда розробників не буде завалена усіма деталями RUP і повним інструментарієм Rational Suite.


Фактично, ці “десять пріоритетів” можуть виконуватися без якої б то не було підтримки автоматизованих інструментальних засобів! Нотатки по проекту, у якій кожному з 10 пріоритетів присвячений свій розділ – фактично дуже хороша відправна точка для управління маленьким проектом. (І я знайшов, що пояснювальні нотатки неоціненні для управління, ранжирування і відстеження запитів на зміни для маленьких проектів!)


Для збільшуються Проектів


Звичайно, якщо розмір та складність проекту ростуть, ці прості засоби застосування десяти пріоритетів скоро стануть неефективними, і потреба в автоматизованих засобах стане більш очевидною. Однак, я все одно рекомендував би керівникам команд починати з “Десяти Пріоритетів” і з “Найкращою практикою” RUP, поступово додаючи, в міру необхідності, інструментальну підтримку, а не починати з спроб відразу повністю використовувати повний набір інструментальних засобів в Rational Suite.


Для сформованих колективів


Для більшості сформованих проектних колективів, які можуть вже застосовувати програмовані процеси і використовувати інструментальні засоби розробки, “Десять Пріоритетів” можуть дати швидкий метод для оцінки балансу між елементами ключових процесів і ідентифікацією та ранжируванням напрямків для вдосконалення.


Для всіх проектів


Звичайно, всі проекти різні, і може здатися, що деякі проекти дійсно не потребують у всіх цих “пріоритети”. У цих випадках, важливо розглянути, що станеться, якщо ваш колектив проігнорує небудь з цих пріоритетів. Наприклад:



Таким чином – дуже ризиковано жити без знання “Десяти Пріоритетів”. Я закликаю Вас використовувати їх як відправну точку для роботи вашого проектного колективу. Вирішіть, що Ви хочете додати, змінити, або прибрати. Після цього вирішите, що ще є дійсно “істотною” для Вашого проекту – незалежно від його розміру – щоб поставити продукт вчасно, в межах бюджету, продукт, який задовольняє реальним потребам ваших замовників!


Інші Пріоритети


Інші організації видали подібні списки пріоритетів з проектування ПЗ.


IEEE Software Magazine, March / April 1997, “Software” s Ten Essentials “, автор – Steve McConnell
В The Software Project Manager “s Network є “16 Critical Software Practices”; Доступна на www.spmn.com.
Software Engineering Institute “s (SEI) Capability Maturity Model (CMM) містить Key Process Areas (KPAs), які можуть розглядатися, як” пріоритети “(див. www.sei.cmu.edu).

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*