Управління вимогами з інструментами лінійки IBM Rational і IBM Telelogic, Комерція, Різне, статті

Введення


За останні 20 років придумано безліч методологій, стандартів, зводів знань, фреймворків (framework) та практик в області розробки ПЗ, таких як RUP, MSF, Agile, ГОСТ, ISO, CMMI, SWEBOK, BABOK і т.д. Я вже не кажу про гору книг з даної тематики. Але всі ці книги і методології вчать нас тому, як має бути в ідеалі в усьому процесі розробки ПЗ. У деяких публікаціях, правда, приділяється увага саме процесу роботи з вимогами (збір, аналіз, документування, повірка і керування вимогами), але все одно вони залишаються занадто теоретизувати.


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


Імовірність помилки в процесі розробки ПЗ


За даними дослідницької організації Standish Group, найбільша кількість помилок відбувається на етапі збору, аналізу та документування вимог. Частка помилок в різних артефактах при розробці ПО представлена ​​на малюнку 1.


Рисунок 1. Частка помилок в різних артефактах при розробці ПО

Далі розглянемо всі п’ять рівнів моделі зрілості для керування вимогами більш докладно.


Рівень 0. Хаос, немає вимог


Даний рівень характерний для більшості організацій пострадянського простору, так як помилково вважається, що головне у всьому процесі розробки – це саме програмування (кодування) розробляється ПО.


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



На доказ сказаного вище можна привести цитату зі статті Джоеля Спольски “Безболісні функціональні специфікації – Частина 1: Навіщо турбуватися?”:


Давайте відвідаємо двох уявних програмістів в двох компаніях. Программістка Бистрякова, із компанії “Скоростиглі Банани Софт”, ніколи не пише специфікації. “Специфікації? Нам не потрібні ніякі … специфікації! “. А от пан Разуміхін з компанії” Хороший Характер Софт “, відмовляється писати код, поки специфікація не буде повністю готова. Це тільки двоє з багатьох моїх уявних друзів.


У Бистрякової і Разуміхіна є щось спільне: вони дбають про проблему зворотної сумісності для версії 2.0 своїх розроблюваних продуктів. Бистрякова вирішує, що найкращий спосіб забезпечити зворотну сумісність – Написати конвертер, який просто перетворює файли версії 1.0 у файли версії 2.0. Вона відразу приступає до реалізації. Пише, пише, пише. Клік-клац-клац по клавішах. Жорсткий диск крутиться. Пил летить. Після приблизно 2 тижнів роботи у неї є стерпний конвертер. Але замовники Бистрякової незадоволені. Її код змушує всіх співробітників в їх компанії відразу переходити на нову версію програми. Найбільший замовник Бистрякової, компанія “Розбірні Деталі Анлімітед”, відмовляється купувати нову програму. Хлопці з “розбірних Деталей” хочуть бути впевнені, що програма версії 2.0 буде продовжувати обробляти файли, створені у версії 1.0, не перетворюючи їх у новий формат. Бистрякова вирішує написати зворотний конвертер і потім почепити його на функцію “Збереження файлу”. Це привносить плутанину, тому що коли ви додаєте в файл, створений під версією 2.0, нововведення цієї версії, вони виглядають працюючими, поки ви не почнете зберігати файл у форматі версії 1.0. Тільки тоді вам буде виведено повідомлення, що властивість, яке ви внесли в файл півгодини назад, не може бути збережено в старому форматі файлу. Отже, розробка зворотного конвертера зайняла ще два тижні, і цей конвертер працює не так вже й добре. Витрачений час – 4 тижні.


У той же час, пан Разуміхін з компанії “Хороший Характер Софт” (скорочено, “ХХС”) – один з тих занудних типів, які відмовляються писати код, поки не буде готова специфікація. Він витрачає 20 хвилин, проектуючи функцію зворотної сумісності, так само, як робила Бистрякова, і видає специфікацію, яка говорить:


* Коли відкривається файл, створений у старій версії програми, він перетворюється в новий формат.


Специфікація показується замовнику, який каже “Хвилиночку! Ми не хочемо відразу переходити на новий формат!”. Г-н Разуміхін розмірковує ще трохи і вносить поправку:


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


Витрачено ще 20 хвилин.


Начальник пана Разуміхіна, схиблений на ООП, дивиться на цю строчку і придумує щось краще. Він пропонує іншу архітектуру.


* Код буде побудований так, щоб використовувати два інтерфейси: V1 і V2. V1 містить всі функції першої версії, а V2, який успадковується від V1, додає все нововведені функції. Тепер метод V1 :: Save буде використовуватися для зворотної сумісності, а V2 :: Save може бути використаний для збереження всіх нововведень версії 2. Якщо користувач відкриє файл через V1 і спробує використовувати функціональність з V2, програма його про це попередить, і він змушений буде або конвертувати файл, або припинити використання нововведень другої версії.


Ще 20 хвилин.


Г-н Разуміхін розсерджений. Ця переробка займе 3 тижні замість 2 спочатку запланованих! Але вона елегантно вирішить всі проблеми замовника, так що він йде і виконує її.


У результаті пан Разуміхін витратив: 3 тижні і 1:00. Витрачений час Бистрякової: 4 тижні, але її програма далеко не так хороша.


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


Рівень 1. Документація вимог


Коли ви почали записувати і зберігати вимоги, то отримуєте відразу незаперечні переваги.


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


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


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


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


Рівень 2. Організація вимог


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


Вимоги повинні бути добре відформатовані. Наскрізна нумерація, постійні схеми, заголовки, шрифти і гарний зміст роблять ваші документи легкими для прочитання, розуміння і подальшого використання. Якщо ваші вимоги добре описані, але погано відформатовані, то ваш документ може стати непотрібним у використанні. Форматування – це простий прийом, але чомусь часто ігнорується. Тут можуть допомогти корпоративні або міжнародні шаблони специфікацій, такі як Концепція (Vision), Специфікація вимог (Software Requirement Specification) і ін Причому у всій організації повинні застосовуватися єдині форматування і шаблони.


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


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


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


Рівень 3. Структурування вимог


Третій рівень моделі зрілості для керування вимогами концентрується на атомарности і типах вимог: бізнес-вимоги або системні, функціональні або нефункціональні і т.д. Також даний рівень додає необхідну інформацію до вимог, крім тексту.


По-перше, ви повинні виділяти вимоги як атомарні одиниці для того, щоб було легше:



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


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



Тільки не робіть поширену помилку – не беріть всі можливі атрибути з іншого проекту. Вам потрібно зрозуміти, які атрибути вам необхідні виходячи зі складності проекту, вимог замовника, методології розробки та інших умов.


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


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


На даному рівні вам уже буде важко керувати вимогами за допомогою простого текстового редактора (MS Word Open або Office Writer), і на допомогу можуть прийти спеціалізовані інструменти: IBM Rational RequisitePro і IBM Telelogic DOORS.


Рівень 3.1. Моделювання вимог


Навіть ідеально структуровані й організовані вимоги можуть не дати повної картини потреби замовника, тому що 20-50 сторінок тексту сприйняти дуже важко. На допомогу нам можуть прийти різного роду моделі, які дозволяють активізувати друга півкуля мозку і поглянути на вимоги “по-новому”.


При вивченні та документуванні бізнес-вимог можуть допомогти модель об’єктів предметної області (Business / Domain Object Model), модель бізнес-варіантів використання (Business Use Case Model) або модель бізнес-процесів (Business Process Model).


При більш детальному вивченні потреб замовника (користувача вимоги) допоможуть модель системних варіантів використання (Use Case Model), вистава користувальницьких класів (View of Participating Classes) або діаграми дій, станів, взаємодії.


Далі йде вже проектування ПЗ: діаграми класів програми та БД, діаграми взаємодії компонентів і класів, діаграми дій і т.д.


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


Рівень 4. Трасування вимог


Реалізація попередніх трьох рівнів моделі зрілості для управління вимогами не дає вам можливості визначати і простежувати взаємозв’язок між вимогами. Система будь-якої складності повинна мати ієрархічність вимог. Наприклад, в RUP (Rational Unified Process) ієрархія вимог простежується між бізнес-потребами, характеристиками ПЗ, варіантами використання і системними вимогами. Можливість відслідковувати дану взаємозв’язок зазвичай називається трасуванням. Трасування дає можливість простежити вплив вимог один на одного і провести аналіз покриття вимог.


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


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


На даному етапі стає очевидно, що управляти вимогами в повному обсязі дуже важко без спеціалізованих засобів. Тут нам на допомогу приходять системи управління вимогами, такі як: IBM Rational RequisitePro, IBM Rational Requirements Composer, IBM Telelogic Doors, Або IBM Telelogic Focal Point.


Рівень 5. Інтеграція вимог


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


По-перше, вимоги служать первинним входом для розробки ПЗ. Тому архітектори ПО повинні бути впевнені (повинні простежити), що всі вимоги реалізовані в дизайні проекту. А розробники повинні зрозуміти, як вимоги співвідносяться з кодом в ПО.


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


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


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


Безумовно, така щільна інтеграція потрібна у великих проектах і вимагає чималих витрат на закупівлю спеціальних засобів з розробки ПЗ на всіх її стадіях. І, безумовно, пальму першості в інструментарії повного життєвого циклу ПЗ (Application Lifecircle Management – ALM) тримають лінійки IBM Rational і IBM Telelogic.


Переваги якісного процесу управління вимогами


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



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

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


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

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

Ваш отзыв

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

*

*