Шукайте істинний сенс вимог

ЕйнарЛандре

Замовники і кінцеві користувачі часто під виглядом вимоги висувають те, що їм здається ефективним рішенням деякої задачі Класичний приклад такого роду призводить Гаррі Хіллейкер (Harry Hillaker), провідний конструктор винищувача F-16 Falcon Перед його групою було поставлено мету спроектувати літак, що розвиває швидкість М2-2, 5, що було (і ймовірно, залишається) вельми нетривіальним завданням, особливо якщо супутня мета полягає в створенні «дешевого» легкого літака Врахуйте, що сила, необхідна для подолання опору повітря, при подвоєнні швидкості польоту зростає вчетверо, і уявіть собі, як це обставина впливає на вагу літака

Коли конструкторська група запитала замовників з ВВС, навіщо їм потрібна швидкість М2-2, 5, ті відповіли: «Щоб літак міг при необхідності вийти з бою» Коли справжня потреба стала очевидною, конструктори змогли вирішити головну проблему і представити працездатне рішення: рухливий літак з високою тяговооруженность, що забезпечує гарне прискорення і маневреність замість високої максимальної швидкості

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

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

Ейнар Ландре (Einar Landre) – професіонал в області програмного забезпечення з 25-річним досвідом роботи в якості розробника, архітектора, менеджера, консультанта й автора / лектора

В даний час працює в групі комерційних додатків фірми StatoilHydro, де займається розробкою додатків, критичних для бізнесу, оцінкою архітектури та оптимізацією процесів розробки Основні сфери його інтересів – сервіс-орієнтовані архітектури, проектування на основі предметної області (domain-driven design), застосування мультіагентов та проектування інтенсивно використовуваних великомасштабних мережевих систем

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

*

*