ня у вузі. Сучасна система навчання передбачає "однопроходний" підхід: початок - прослухав курс - здав залік - кінець. Насправді ж ситуація "Кінець" в реальному житті не настає ніколи. Або, якщо висловлюватися точніше, є вкрай небажаною - для розробника вона означає завершення життєвого циклу продукту і відхід його з ринку (або зняття з експлуатації у замовника). Нормальною має бути ситуація, коли після визначення вимог до системи, аналізу, розробки, реалізації та тестування (у тому числі і в процесі експлуатації) виникали б нові вимоги на основі реакції користувачів - і, відповідно, цикл повторювався б знову.
На рівні учасників процесу (Актантов) кожен фахівець повинен володіти добре формалізованим інтерфейсом: отримувати вхідні дані і генерувати потрібний результат, поза Залежно від дій сусідніх ділянок.
Суть ідеї - у розмежуванні повноважень та незалежності операцій: згідно з уніфікованим Процесу, реалізація і навіть тестування повинні починатися так само скоро, як скоро з'являються перші дані від архітекторів. У результаті запити на виправлення (Requests for Change) будуть генеруватися на самих ранніх етапах (в результаті тестування) і проходити з самого початку через ланцюжок аналізу, реалізації та знову тестування. До того часу як система почне експлуатуватися у замовника, нормальний виробничий цикл вже буде приведений в дію.
Таким чином, це не відхід від вирішення проблем, але розподіл їх на більш ранні періоди розробки - так би мовити, "По невеликій проблеми кожен день". При цьому стає неможливою ситуація "всі гроші ми витратили, але нічого не вийшло" - завжди можна контролювати кількісні параметри прогресу. У гіршому випадку залишається вибір: або завершити роботу на ранньому етапі, частково захистивши інвестиції, або довести розробку до проміжного фінішу (наприклад, створивши робочу бібліотеку компонент, яку можна використовувати в іншому проекті або продавати незалежно). Принаймні, в результаті використання Уніфікованого Процесу буде створена унікальна база знань (наприклад, в вигляді UML-діаграм) в предметній області, що саме по собі є ліквідним активом.
Отже, завдання зводиться до організації циклічного, формалізованого та автоматизованого процесу розробки. Саме для організації такого процесу "Борланд" ретельно підібрала і допрацювала ряд продуктів, які тепер складають основу нових середовищ розробки.
CaliberRM: аналізуй
В основі всіх нових (або придбаних) продуктів Borland лежить ряд евристик, згенерованих в університеті Carnegie-Mellon, з яким у цієї компанії давні і міцні зв'язки. Основна теза всіх досліджень можна сформулювати таким чином: "чим більше буде думатиметься на початку, тим менше доведеться переробляти в кінці ". Було досліджено достатня кількість проектів на предмет "Попереднього вивчення вимог та кількості подальших переробок у системі ". У чисельному вираженні це виглядає приблизно так: якщо витрати на визначення попередніх вимог складають 5-6%, то переробки зазвичай обходяться в суму на рівні 70-80%! Якщо ж на початковому рівні затратити близько 15% ресурсів на визначення та формалізацію вимог, то рівень переробок складе приблизно 30-40%.
Звичайно, насправді за всім цим стоять цілком конкретні й більш осмислені числові величини, але загальний зміст ясний: терміни розробки можна скоротити, а вартість знизити, якщо більше часу приділити попередньою плануванню.
На етапі визначення вимог до системі важливо надати отриманим від користувача відомостями формальний і детермінований вигляд. Також важливо розділити повноваження: окрема людина або система збирає бажані вимоги, Change Requests, такі як виправлення помилок або додавання/модифікація функціональності і інтерфейсу. Команда архітекторів приймає рішення по кожній позиції: реалізувати чи в найближчому багфіксів, відкласти чи до нової версії або ж взагалі "до кращих часів ". Ясно, що з точки зору кожного користувача його вимоги - найважливіші. І якщо не створити бар'єр між користувачем і розробником, то останній може бути просто блокований запитами на зміну, далеко не всі з яких варті уваги.
Для збору і формалізації вимог до програмному продукту (але фактично це може бути використано і для будь-яких інших систем) призначений новий (для "Борланд") інструмент - CaliberRM. У назві присутнє RM, що означає Requirement Manager - то є система для обліку, класифікації та відстеження життєвого циклу вимог. Природно, такий інструмент працює в мережевому оточенні і призначено для групової роботи із загальним репозитарієм. Також зовсім у дусі часу існує кілька методів доступу до інформації: окремі інструменти, інтегровані в IDE "спливаючі" модулі, міжплатформна графічний інтерфейс Java, доступ через веб-браузер.
Розглянемо трохи докладніше функції CaliberRM, оскільки цей інструмент може бути корисний не тільки в розробці програмних продуктів, але також і в будь-який інший галузі.
Сист...
