Оценка авторской мысли

Какова цель автора?

На какой вопрос автор пытается дать ответ?

Какую информацию автор использует в своих умозаключениях?

Каковы главные выводы автора?

Каковы основные концепты и идеи в мышлении автора?

Из каких предположений исходит автор?

С какой позиции автор рассматривает вопрос?

Если автор прав, то что из этого следует?

Конспект

Структура процесса проектирования (в который включается вообще-то полный набор активностей разработки, начиная со сбора требований и заканчивая раскаткой артефактов по средам) не тождественна структуре конечного продукта.

Методы структурного программирования предполагали такую тождественность и в результате справляются с документированием конечного дизайна, но не с документированием процесса дизайна, как процесса формулирования проблем, поиска решений, оценки гипотез и т.п.

Еще есть подход, при котором процесс проектирования рассматривается как последовательность трансформаций каких-то описаний системы, в конечном итоге приводящая к созданию “исполняемого” описания, вроде кода, транслируемого в реальные инструкции во время выполнения (IEEE, 1988). При таком подходе сохраняются трансформации рабочих продуктов, но опять же теряется информация о принятых проектных решениях и их причинах (Mostow, 1986; Balzer, 1988).

Существует также и модель решений (Dangupta, 1989; Conklin, 1988), которая принимает во внимание:

1. Наличие слабо определенной проблемы, т.е. необходимость идентифицировать и корректно сформулировать решаемую проблему.
2. Наличие нескольких способов решения проблемы, а также понимание того, что каждое предложенное решение может содержать новые проблемы, таким образом, процесс решения рекурсивен
3. Сложность выбора, практическая невозможность принять объективно наилучшее решение, поэтому выбирать будем наименее плохое решение, а затем его пересматривать. О подобных ограничениях и подходе к выбору решений речь идет и в Discussion of the Method.
4. Решение всегда выбирается из нескольких альтернатив.

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

Процесс решения проблем

Это очень творческий процесс, которым очень сложно эффективно управлять по ряду причин. Драйверы исследований и поиска решений варьируются (риски, восприятие возможностей, личные предпочтения, прямые управленческие директивы). Порядок исследований со стороны может казаться хаотичным и неопределенным. Любые требования по стандартизации решений ограничивают творчество и не дают сильным дизайнерам находить прорывные решения. Тем не менее эту деятельность можно структурировать, только не с помощью структуры конечной системы (ее еще нет), а с помощью структурированного процесса.

Стоит ожидать, что сильные дизайнеры будут находить более эффективные / оптимальные решения. Однако, если система будет сопровождаться другими людьми, процесс нахождения решения необходимо документировать. Только так сопровождение можно делегировать и машстабировать, и использовать знания и опыт сильных дизайнеров не только для создания конечной системы, но и для развития / образования / обучения других участников команды.

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

Структура решения

Решение - это расширение документации по системе, представляющее собой формализованную фиксацию всех принятых проектных решений в следующем четырехчастном формате:

1. Проблема. Описание проблемы, которую призвано устранить данное решение.
2. Возможности. Набор возможных решений проблемы. Запись всех обнаруженных возможных путей решения позволяет не перебирать в будущем заведомо тупиковые решения, а также отметить те опции, которые не были в достаточной степени проработаны, и к ним можно будет вернуться при наличии ресурсов.
3. Решение. Выбранная для решения проблемы возможность.
4. Обоснование. Причина, по которой была выбрана именно эта возможность. Может принимать множество форм: формальное (математическое) доказательство, неформальные аргументы в пользу решения, результаты спайка (прототипа, исследования, анализа литературы), нетехнические причины (корпоративные политики, правовые ограничения и т.п.), анализ стоимости решений и т.д.

Поскольку каждое решение может само по себе выдвигать новую проблему, то получается цепочка решений. Последнее решение в этой цепочке должно ссылаться на какой-либо рабочий продукт / артефакт, документирующий / описывающий принятое решение в формате документации системы. Это может быть и фрагмент исходного кода, например. Началом каждой такой цепочки должно быть требование или спецификация.

Решения могут зависеть друг от друга (ситуация, когда второе решение устраняет проблему, созданную первым решением), а могут обосновывать друг друга. Это различие важно при управлении изменениями требований и пересмотре цепочек решений.

Любой из узлов в таком графе может быть связан с каким-либо фрагментом рабочей документации по системе, в том числе и исходным кодом. Таким образом обеспечивается трассируемость от артефактов до порождающих их требований через цепочку проблем и их решений. Парадигма DBSD оказывается безмасштабной, любую фазу процесса разработки можно рассматривать как процесс решения проблем и ее результирующие рабочие продукты можно структурировать через граф решений.

Использование DBSD при проектировании

1. Поддержка процесса проектирования за счет возможности исследовать варианты в любое удобное время и не принимать решения сразу, а просто фиксировать варианты и их сильные / слабые стороны.
2. Облегчение понимания программы (через трассировку от кода к требованиям) и объема изменений (через трассировку от требований к коду)
3. Обеспечение консистентности решений за счет того, что обоснование одного конкретного решения ставит более общую проблему, решает ее на более общем уровне, а затем применяет найденное решение к известному частному случаю.
4. Обнаружение псевдо-проблем, созданных “проектированием в требованиях”, т.е. ситуациями, когда требования пишутся исходя из уже придуманного решения. Это опять же частное решение без выявления общей проблемы.

Проведение анализа затрат и выгод в разработке ПО - сложная затея, т.к. затраты обычно нужно нести прямо сейчас, а выгоды отложены во времени ¹. Результат такого анализа напрямую зависит от продолжительности рассматриваемого периода, он должен включать в себя как период с преобладающими прогрессивными активностями (добавление новых фич), так и период с антирегрессионными активностями (документирование, рефакторинг). Эти два вида активностей сменяют друг друга с определенной цикличностью, см. Belady and Leman (1976). Усугубляет ситуацию еще и тот факт, что для времени выполнения софта вообще не нужно ничего, кроме исходного кода, поэтому всю остальную документацию иногда люди склонны рассматривать, как излишнюю.