97 этюдов для архитекторов программных систем

Ищите истинный смысл требований Эйнар Ландре

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

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

Выводы из этого урока в равной степени справедливы и в области разработки программного обеспечения. Узнав у заказчика истинный смысл запрашиваемой возможности или требования, архитектор сможет проникнуть в суть проблемы и, если повезет, предложить решение более качественное и экономичное по сравнению с тем, на котором настаивает клиент. Повышенное внимание к сути требований упрощает и расстановку приоритетов: самые значимые для заказчика требования становятся определяющими.

Как же следует действовать? В манифесте гибкой (agile) разработки есть принцип, который ко многим случаям подходит очень хорошо: «Сотрудничество важнее контракта». С практической точки зрения это подразумевает проведение семинаров и встреч, на которых архитекторы анализируют потребности заказчика, помогая ему ответить на вопрос «Почему?». Учтите, что поиск ответа на этот вопрос может оказаться весьма непростой задачей, потому что в процессе анализа требований речь зачастую идет о неявных допущениях и подразумеваемых знаниях. На таких встречах следует избегать дискуссий по поводу технических решений, потому что они переводят обсуждение из предметной области заказчика в область программирования.

Эйнар Ландре (Einar Landre) — профессионал в области программного обеспечения с 25-летним опытом работы в качестве разработчика, архитектора, менеджера, консультанта и автора/лектора. В настоящее время работает в группе коммерческих приложений фирмы StatoilHydro, где занимается разработкой приложений, критических для бизнеса, оценкой архитектуры и оптимизацией процессов разработки. Основные сферы его интересов — сервис-ориентированные архитектуры, проектирование на основе предметной области (domain-driven design), применение мультиагентов и проектирование интенсивно используемых крупномасштабных сетевых систем.