Rational Unified Process – як досягти 2-го рівня CMM, Комерція, Різне, статті

Зміст



Ви хочете обійти своїх конкурентів?

Значить, Ви повинні гарантувати високу якість свого програмного продукту, що відповідає потребам кінцевих користувачів, в межах передбачуваного тимчасового графіка і бюджету. Багато компаній вкладають гроші в поліпшення свого процесу розробки і отримують гарну віддачу. У статті “Сучасні моделі якості програмного забезпечення“Автори, з посиланням на західні джерела, наводять такі цифри: середній рівень повернення вкладень у поліпшення процесу складає від 5:1 до 8:1.

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

Існує безліч підходів до забезпечення якості ПЗ і відповідних їм стандартів. Але оскільки ця стаття, як я сподіваюся, носить чисто практичний характер, ми зупинимося лише на одному з них – На Моделі зрілості процесу розробки ПЗ (Capability Maturity Model – CMM) Інституту системного програмування при університеті Карнегі-Меллон, США (SEI – Software Engineering Institute). Далі ми зупинимося тільки на те, як організація може використовувати Rational Unified Process (RUP) І засоби його інструментальної підтримки для досягнення 2-го (Повторюваний) рівня зрілості CMM. Про досягнення 3-го (Певний) рівня ми поговоримо в наступній статті.


Кілька слів про порядок викладу матеріалу

Ця перша стаття “дилогії” містить короткий огляд CMM: тільки те, що необхідно для розуміння і використання подальшого матеріалу. Тим, хто хоче більш докладно познайомитися з концепціями CMM, можна порекомендувати вже згадану статтю “Сучасні моделі якості програмного забезпечення”. Там же пропонується певний глосарій. Допитливі читачі можуть прочитати першоджерело: Mark C. Paulk et al, “Key Practices of the Capability Maturity Model – Version 1.1”, Software Engineering Institute – Carnegie Mellon University.

Розділи, присвячені використанню RUP для досягнення 2-го (ця стаття) і 3-го (наступна стаття) Рівнів CMM, представлені по одному планом:


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

Короткий огляд CMM

Модель зрілості процесу розробки ПЗ (CMM) Інституту системного програмування (SEI) – це каркас, який описує елементи ефективного процесу створення програмного забезпечення. CMM описує еволюційний шлях удосконалення процесу від незрілого до зрілого, упорядкованого процесу.

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

CMM має п’ять рівнів зрілості організації від 1-го до 5-го (див. рис. 1).

Рисунок 1. П’ять рівнів зрілості процесу в організації, що визначаються CMM SEI

Кожен рівень зрілості складається з ключових областей процесу (Key Process Areas – KPA), і кожен KPA ідентифікує пакет пов’язаних дій. При виконанні всіх цих дій досягається набір цілей, вважаються важливими для встановлення можливості процесу на даному рівні зрілості.

Характеристики 2-го рівня, “Повторюваний”

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

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

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

KPA 2-го рівня:


2-й рівень і Rational Unified Process

Управління вимогами

Мета управління вимогами полягає в тому, щоб встановити спільне з замовником розуміння його вимог до програмного проекту. Ця угода із замовником є ​​базою для планування (як описано в KPA “Планування проекту ПО”) та управління (як описано в KPA “Відстеження і нагляд за проектом”) програмного проекту. Управління зв’язками з замовником залежить від ефективності подальшого процесу управління змінами (як описано в KPA “Управління конфігурацією ПЗ”).

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

Артефакти RUP, які фіксують вимоги в технічному контексті:



Артефакти RUP, що описують прецеденти й сценарії (вимоги), які розробляються для використання в контексті управління:



Всі ці артефакти узгоджені і підпорядковані обслуговування управління змінами.


Мета 1: Системні вимоги, що пред’являються до програмного забезпечення, управляються так, щоб встановити базові лінії для проектування та управління програмним забезпеченням.


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



RUP узгоджується з CMM щодо угод по вимогам, управління ними, відстеження і базування.


Мета 2: Плани, продукти і дії при розробці зберігаються сумісними з системними вимогами, що пред’являються до програмного забезпечення


Основне в цієї мети CMM – гарантія того, що поставлені системи виконують вимоги користувача. RUP допомагає організаціям досягти цієї мети двома шляхами:



Документи управління в RUP:



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


RUP рекомендує кожному проекту заснувати Групу управління змінами (CCB), яка повинна вирішувати питання про можливості і впливи (бюджетних, технічних і т.д.) запропонованих змін або виявлених дефектів. Щоб допомогти операціями CCB, RUP рекомендує використання інструменту / середовища конфігураційного управління і управління версіями.


Планування проекту ПО



Мета планування проекту програмного забезпечення полягає в тому, щоб встановити розумні плани розробки програмного забезпечення та управління програмним проектом. Ці плани необхідні для управління програмним проектом (як описано в KPA “Відстеження і нагляд за проектом”). Без реальних планів ефективне управління проектом не може бути реалізоване.


Мета 1: Оцінки програмного забезпечення задокументовані для використання в плануванні та відстеження програмного проекту.


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


Rational Unified Process використовує наступні класи метрик:



Мета 2: Дії та зобов’язання проекту розробки програмного забезпечення заплановані і документовані.


Документи Rational Unified Process, які фіксують проектні плани та зобов’язання:



Відстеження і нагляд за проектом



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


Мета 1: Фактичні результати і характеристики простежуються щодо програмних планів.


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


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


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


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


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


Мета 2: Зміни в програмному забезпеченні узгоджуються з групою управління і з зацікавленими особами.


Керований ітераційний процес розробки, як це описано в RUP, гарантує, що співвласники отримують регулярну інформацію про просування проекту і будь-які необхідні зміни не порушують хід проекту. Запропоновані зміни розглядаються Групою управління змінами (CCB), щоб гарантувати, що вони реальні й укладаються в графік виконання проекту.


Управління субпідрядниками



Мета управління субпідрядниками полягає в тому, щоб вибрати кваліфікованих субпідрядників для розробки компонентів програмного забезпечення та ефективно ними управляти. Це поєднання об’єднує інтереси керування вимогами, планування проекту та управління програмним проектом в загальне адміністративне управління, поряд з необхідною координацією забезпечення якості та управління конфігурацією програмного забезпечення, і пред’являє відповідні вимоги до управління субпідрядниками.


Мета-1: Генеральний підрядник вибирає кваліфікованих субпідрядників.


Мета 2: Генеральний підрядник і субпідрядники домовляються про спільну роботу.


Ціль 3: Генеральний підрядник і субпідрядник підтримують тривалі відносини.


Мета 4: Генеральний підрядник відстежує фактичні результати субпідрядника і ефективність виконання його зобов’язань.


Ці цілі знаходяться поза контекстом дій RUP і залежать від організації.


Якщо субпідрядник поки не використовує RUP, його інструментальні засоби, методи і механізми доводяться до субпідрядників так, щоб процес залишався однорідним


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


Забезпечення якості ПЗ



Мета забезпечення якості ПЗ полягає в тому, щоб забезпечити керівництво відповідним поданням про процес, що використовується в програмному проекті і створюваних програмах. Забезпечення якості ПО – це невід’ємна частина більшості процесів управління та розробки програмного забезпечення.


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


Мета 1: Дії забезпечення якості ПО заплановані.


Планування завдання забезпечення якості ПО – це відповідальність організації. Однак RUP має ряд атрибутів, які надаються для формування ефективної проектної програми забезпечення якості.


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


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


Мета 2: Відповідність програмних продуктів і дій застосовуваним стандартам, процедурам і вимогам об’єктивно перевірено.


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


Ціль 3: беруть участь групи і особи поінформовані щодо дій та результатів забезпечення якості ПЗ.


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



Мета 4: Неузгоджені проблеми, які не можуть бути дозволені в межах програмного проекту, вирішуються вищим керівництвом.


Це знаходиться поза контекстом дій RUP і залежить від організації. Проте, процес управління змінами, описаний в RUP, допускає механізм, за допомогою якого неузгодженості можуть бути задокументовані і представлені для вирішення.


Управління конфігурацією ПЗ



Мета управління конфігурацією ПЗ полягає в тому, щоб встановлювати і підтримувати цілісність програмного забезпечення проекту протягом усього його життєвого циклу. Управління конфігурацією ПЗ – це невід’ємна частина більшості процесів управління та розробки програмного забезпечення.


Мета 1: Дії управління конфігурацією ПЗ заплановані.


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


RUP має два головних інструменту для визначення того, як повинні підтримуватися авуари проекту розробки програмного забезпечення, і як вони повинні бути інтегровані:



План управління конфігурацією, ініціалізіруемих в стадії Початок, описує наступне:



План виконання інтеграції містить подробиці щодо конфігураційних елементів, які повинні бути створені, і порядок, в якому вони повинні бути інтегровані в даній ітерації.


Мета 2: Вибрані для роботи програмні продукти ідентифіковані, управляються і доступні.


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


Ціль 3: Зміни в ідентифікованих для роботи програмних продуктах управляються.


RUP надає проекту підтримку CCB і має систему управління змінами, щоб відповідно керувати, оцінювати, відстежувати і виконувати запити зміни.


Мета 4: беруть участь групи і особи поінформовані щодо стану та змісту базових ліній програмного забезпечення.


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

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


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

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

Ваш отзыв

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

*

*