Практика та підходи до відновлення вимог до ІС

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

Що таке “відновлення вимог”?


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


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


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


Тепер дія – відновлення. У тлумачному словнику одне з тлумачень звучить так: відтворення у свідомості, в уяві, в пам’яті чогось забутого. Так як відтворення в пам’яті для процесу розробки явно недостатньо, то відновлювати необхідно в проектних артефактах.


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


Як ми потрапили в цю ситуацію і чому хочемо вибратися?


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



Як ви зрозуміли, список відсортований за зростанням складності процедури відновлення.


Перше питання, яке потрібно поставити перед собою у разі нестачі документації, наступний: “А чи потрібно взагалі її відновлювати?”


Давайте розберемося, навіщо можуть знадобитися вимоги до вже функціонуючим системам:



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


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


Якщо для вас стало остаточно ясно, що вимоги відновлювати потрібно, то постає наступне питання:







Який обсяг вимог достатній?


Відповідь на це питання випливає безпосередньо з відповіді на питання “Хто буде споживачем?”.


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



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



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


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


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


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


Тепер потрібно визначити:







Які нам потрібні артефакти?


Розглянемо набір артефактів дисципліни “Управління вимогами” з RUP. Це:



Зі списку необхідних при відновленні артефактів відразу ж можна виключити Запити зацікавлених осіб – запити до розробленої системі збирати безглуздо.


Концепція системи – необхідний артефакт. Якщо немає ресурсів на відновлення, то найправильніше – відновити тільки концепцію.


Глосарій – дуже корисний артефакт. Зручніше мати один глосарій на предметну область, а не окремий документ на систему.


Додаткові специфікації – нефункціональні вимоги до аналізованої системі – відновлювати необхідно. Якщо система невелика, то нефункціональні вимоги можна фіксувати окремим розділом в Концепції.


Модель прецедентів – якщо планується подальша розробка системи, то модель потрібна.


Опис прецеденту (розкадровка) – якщо планується подальша розробка системи, то розкадровка потрібна. Крім того, добре мати поведінкові діаграми прецедентів: діаграми активності, послідовності, станів. Якщо мається керівництво користувача системою, то воно може замінити опису прецедентів.


План управління вимогами – необхідний. У ньому потрібно визначити межі відновлюваних вимог і організацію процесу.


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


Крім артефактів вимог може виявитися корисним відновити деякі аспекти бізнес-моделі:








Трохи про ГОСТ


Досить часто для фіксації вимог в організаціях використовують документ “Технічне завдання”. Стандарт його змісту викладений в ГОСТ 34.602-89. Він говорить про те, що в документі мають бути наступні розділи:



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

  2. Призначення і цілі створення системи;

  3. Характеристика об’єктів автоматизації;

  4. Вимоги до системи;

  5. Склад і зміст робіт зі створення системи;

  6. Порядок контролю і приймання системи;

  7. Вимоги до складу та змісту робіт з підготовки об’єкта автоматизації до введення системи в дію;

  8. Вимоги до документування;

  9. Джерела розробки.

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


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







Як керувати відновленням вимог


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


Робочими продуктами проекту будуть документи і моделі, а не код.


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


Безпосередньо проект не принесе прибутку, так як він внутрішній. Однак інші проекти (або сервіси), використовуючи його результати, повинні скоротити витрати.


Потрібно відзначити, що відновлення вимог потрібно організовувати як окремий проект, а не вбудовувати його в якій або проект з розробки. Чому? У цих проектів різні цілі. Крім того, легше управляти ресурсами. Фактично такий проект ми закінчуємо після виконання двох фаз RUP: Початок і Уточнення.


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


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


На підставі діаграми прецедентів відновлюється Концепція. Є кілька аспектів цієї роботи. Якщо ви відновлюєте документацію до великої кількості невеликих утиліт для подальшого перенесення їх на нову платформу, то має сенс групувати їх і створювати Концепцію на групу. Угрупування проводиться таким чином, щоб у наступних проектах розробки вся група стала частинами однієї майбутньої системи. При відновленні Концепції до великої системі можна розбити її на підсистеми і відновлювати Концепцію для кожної підсистеми. Правило розбиття залишається таким же, як і для проектів розробки: в документі має бути описано від 25 до 99 функціональних можливостей. У ході роботи над Концепцією необхідно, наскільки це можливо, зрозуміти і зафіксувати бізнес-цілі, які вирішуються за допомогою аналізованої системи.


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


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


Джерелами даних для моделі сутностей предметної області служать результати реверс-інжинірингу вихідного коду і керівництво користувача.


Для опису прецедентів моделі поведінки предметної області джерелами даних служать керівництво користувача та алгоритми функціонування системи.







Витязь на роздоріжжі (або хто всім цим займеться?)


Як показує практика, головне питання при відновленні вимог: “Кому все це доручити, коли всі зайняті?”. Як і всі подібного роду питання, це питання ресурсних пріоритетів. Де взяти ресурс? У цієї проблеми існують три основні варіанти рішення.



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

  2. Виділяємо на такий проект частину часу наявних фахівців. Наприклад, за планом на це відводиться п’ять годин на тиждень. Хочу відзначити, що витрачання цього ресурсу на інші завдання повинне бути зменшене на таку ж кількість часу. Плюс в такому підході – вся проектна команда збалансовано збільшує компетенцію по аналізованій системі. Ще одна позитивна якість при такому підході – можна відновити вимоги більш глибоко, особливо якщо документацію відновлює та ж команда, яка розробляла ПО. Мінусом при такому підході є відволікання фахівців від інших проектів. При описуваному підході є можливість більш гнучко підходити до планування процесу. Можна робити як повне відновлення проектної документації, так і часткове. При частковому – відновлюється той обсяг вимог, який необхідний для подальшої розробки. Спочатку можуть бути відновлені старі вимоги, на їх основі формуються нові і після цього проводиться реалізація. Наприклад, якщо допрацьовується модуль системи, то спочатку відновлюються вимоги до нього, які не зміняться в ході доробок, потім формуються вимоги по доопрацюванню.

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

Однак всі три підходи мають право на життя.


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


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


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







Гірше граблів тільки дитячі граблі. Помилки і як їх уникнути


Найбільш часто зустрічаються наступні помилки.



  1. Процес відновлення не організується як окремий проект. Це призводить до того, що він просувається (якщо просувається) як доведеться. Немає керівника, який несе за нього відповідальність. Не виділяється ресурс для цієї роботи, особливо в тому випадку, коли відновлення проводиться за другим варіантом. Висновок: процес відновлення повинен бути виділений в окремий проект.

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

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

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

  5. Відновлюємо вимоги, а потім забуваємо про них. У результаті вимоги як поламаний годинник – два рази на добу показує точний час. В іншому ними користуватися не можна. Висновок: відновлювати вимоги має сенс тільки одночасно з постановкою процесу розробки (зокрема, процесу управління вимогами), щоб надалі проектна документація завжди була в актуальному стані.

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


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

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

Ваш отзыв

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

*

*