Який хороший метод зробити легку оцінку архітектури?

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

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

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

Хтось має досвід робити легку оцінку архітектури на передній панелі? Якщо так, то які хороші практики?

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

Я можу порекомендувати дві книги, які вивчать ці два (дещо пов'язані) підходи.

Ентоні Латтанце « Архітектурне програмне забезпечення інтенсивних систем» впроваджує методологію дизайну орієнтованої на архітектуру та висвітлює невеликі оцінки сценарію. Ви можете впізнати Lattanze з майстерні якості атрибутів SEI, і там є подібні ідеї.

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

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

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

Перш ніж почати:

• Сценарії атрибутів якості або ризики, визначені пріоритетом (можуть бути неофіційними, якщо це все, що у вас є)
• Чітке визначення для рішення "ходити / не ходити" (як ви знаєте, що архітектура "достатньо хороша")
• Останній зріз опису архітектури (артефакт, який ви оцінюєте)

Сідайте на сесію з оцінки:

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

Після закінчення сеансу:

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

Щоб допомогти вам відчути, як може виглядати підхід, заснований на сценаріях, є деякі публічні документи з найважливішого проекту, над яким я працював у школі. Документація трохи груба, але вона може допомогти навести декілька прикладів підходу, заснованого на сценаріях, в контексті ACDM. Ми були командою з 5 осіб і створили типовий веб-додаток, близько 35 KLOC Java / GWT.

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

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