Створення архітектури як мистецтво балансу

Ренді Стаффорд

Зіставте інтереси сторін з технічними вимогами

Коли мова заходить про розробку архітектури програмного забезпечення,

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

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

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

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

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

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

Біографія автора наведена на стор 25

Джерело: Форд Н, Найгард М, де Ора Б, 97 етюдів для архітекторів програмних систем – Пер з англ – СПб: Сим-вол-Плюс, 2010 – 224 с, Мул

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


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

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

Ваш отзыв

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

*

*