70. Планування повторного використання програмних компонентів.

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

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

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

• Потрібно розуміти, які компоненти потенційно придатні для перевикористання;

• Потрібно усвідомлювати потреби проекту. Для деяких проектів це легко: «ми потребуємо точності в тому, що було зроблено раніше», для інших — складно:

“ми ніколи не працювали в даній області, отже, не можемо знати, у чому реально бідуємо”;

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

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

• Слід виділяти розроблювачам час для вивчення можливого перевикористання.

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

аналогічного компонента з порівнянною трудомісткістю.

При розробці компонента, що претендує на своє перевикористання, необхідно мати на увазі наступне:

• Не обов'язково розбудовувати перевикористовувані компоненти (класи, бібліотеки та ін.) у рамках поточного проекту. Більше того, це може привести до обмеження сфери застосування поточними потребами. Найкраще провести комплексний і незалежний від проекту аналіз потенційних можливостей компонента, очистивши його від особливостей конкретного застосування;

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

зусилля на відстеження зв'язків. По-друге, вона може розглядатися як зразок, приклад для наступних перевикористань;

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

• Побудова перевикористовуваних компонентів збільшує вартість. Як правило, вартість програмного забезпечення, що передбачає пері використання в три рази більше, чим для специфічних компонентів. Хоча ця вартість може розподілятися між декількома проектами або ітераціями, реальна вигода від пері використання з'являється тільки після троєкратного застосування компонента.