Використовуйте кількісні критерії

Кейт Брайтуейт

«Швидкий» не може бути вимогою Як і «що володіє хорошим часом відгуку» Або, скажімо, «розширюваний» Головна причина полягає у відсутності обєктивних критеріїв виконання таких вимог Але користувачам ці характеристики все одно потрібні Завдання архітектора – подбати про те, щоб система володіла необхідними якостями, а також збалансувати неминучі протиріччя, що виникають між ними Без обєктивних критеріїв архітектор залежить від примх замовника («Ні, я не можу прийняти програму – вона працює недостатньо швидко») і розробників, одержимих навязливими ідеями («Ні, програма ще не готова – вона працює недостатньо швидко »)

Зазвичай ми намагаємося записати всі подібні побажання, як і будь-які інші вимоги Але цей запис дуже часто виглядає як набір туманних епітетів: «гнучкий», «зручний у супроводі» і так далі Однак всі критерії такого роду (при достатній старанності навіть «зручність використання») можуть вимірюватися в числових величинах, для яких можна встановити порогові значення Якщо цього не зробити, користувачі позбудуться обєктивних підстав для прийняття системи, розробники втратять корисні орієнтири, якими вони можуть керуватися під час роботи, а подання архітекторів про систему втратить чіткість

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

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

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

«Система повинна реагувати на вхідні дані користувача не більш ніж за 1500 мс При стандартній навантаженні (обумовленої як ..) середній час відгуку має лежати в інтервалі від 750 до 1250 мс Час відгуку менше 500 мс не сприймається користувачами, тому його падіння нижче цього порога оплачуватися не буде »А ось це вже можна назвати вимогою

Кейту Брайтуейту (Keith Braithwaite) вперше заплатили за розробку програмного забезпечення в 1996 році, хоча до цього він багато років займав-ся програмуванням на аматорському рівні Після першого проекту – супроводу компілятора, написаного з використанням lex і УАСС, – він зайнявся спочатку моделюванням поширення мікрохвиль для планування мереж GSM, а потім розрахунком на C + + сезонних коливань попиту на повітряні перевезення Перейшовши на посаду консультанта (і одночасно на мову Java), він познайомився з CORBA і EJB, а потім і з тим, що тоді називалося «електронною комерцією» В даний час Кейт працює провідним консультантом у фірмі Zuhlke, де очолює Центр гнучкої розробки

Джерело: Форд Н, Найгард М, де Ора Б, 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>

*

*