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

Зміст


Ми продовжуємо знайомитися з можливостями Rational Unified Process (RUP), Які можуть допомогти Вам досягти 2-го і 3-го рівнів зрілості CMM.

В попередній статті Вам був запропонований короткий огляд CMM і описані можливості RUP, що забезпечують досягнення 2-го рівня CMM. У цій статті йдеться про можливість досягнення 3-го рівня.

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

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

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

В CMM цей пристосований процес називається проектно певним процесом розробки ПЗ.

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

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

KPA 3-го рівня:



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


Фокусування організації на процесі


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


Мета 1: Дії розробки та уточнення процесу розробки ПО скоординовані у всій організації.


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


Мета 2: Сильні і слабкі сторони процесу розробки ПО ідентифіковані щодо стандарту процесу.


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



Ціль 3: Розвиток процесу рівня організації і дії уточнення заплановані.


Цей мета 3-го рівня повністю залежить від впроваджує організації.


Визначення процесу в організації


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


Мета 1: Стандартний процес розробки ПЗ в організації розроблено і підтримується.


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


Мета 2: Інформація, пов’язана з використанням стандартного процесу проектів розробки ПЗ в організації зібрана, розглянута і зроблена доступною для всіх проектів.


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


Малюнок нижче ілюструє певну рекомендовану RUP інфраструктуру визначення процесу в організації.

Рисунок 2. Загальний і проектно певні процеси і засоби їх підтримки (середа) в організації

Програма навчання

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

Мета 1: Дії навчання заплановані.

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

Крім того, пов’язані з RUP курси підтримки включають:



Мета 2: Навчання забезпечує розвиток навичок і знань, необхідних для виконання ролей управління та виконання програмного проекту.


Ціль 3: Особистості в групі розробки програмного забезпечення та в пов’язаних з нею групах отримують навчання, необхідне для виконання своєї ролі.


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


Інтегральне управління розробкою ПЗ


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


Мета 1: Проектно певний процес розробки ПЗ – це пристосована версія стандартного процесу в організації.


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


Мета 2: Проект запланований і управляється згідно проектно певного процесу.


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


Проектування програмного продукту


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


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


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


Мета 2: Програмні продукти зберігаються сумісними один з одним.


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


Міжгрупова координація


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


Мета 1: Вимоги замовника узгоджені з усіма взаємодіючими групами.


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


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


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


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


Експертна оцінка


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


Мета 1: Дії огляду програм заплановані.


Як описано в цілях KPA “Забезпечення якості” для 2-го рівня, кожна дія в межах RUP має окрему дію огляду.


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


Мета 2: Дефекти в продуктах роботи ідентифіковані і вилучені.


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



Висновок


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


За рамками цієї статті залишилася проблема впровадження в організації процесу розробки ПЗ, що базується на RUP. Кращим джерелом знань з цієї теми є, безумовно, сам Rational Unified Process. Російськомовним читачам можна порекомендувати вже згадуваний цикл статей “Введення в Rational Unified Process”, зокрема – випуск 14 і кілька наступних, які, я сподіваюся, будуть закінчені і опубліковані на сайті Interface Ltd в найближчому майбутньому.


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

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


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

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

Ваш отзыв

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

*

*