Методики принятия решений при разработке ПОСложный технологический процесс разработки программного обеспечения, следование которому дает возможность выпускать продукты в срок, с высоким качеством и в рамках установленного бюджета, включает в себя инженерные, управленческие и поддерживающие процессы, позволяющие проектной команде вести согласованную и контролируемую работу. Один из важнейших — процесс принятия решений. Разработка продукта на разных его фазах всегда сопряжена с принятием серьезных решений, как в управленческой, так и в инженерных сферах проекта — использование формальных методов позволяет принимать решения на основе объективного анализа фактов, четко обосновывать сделанные выводы и оценивать последствия принятых решений, тем самым сводя к минимуму риски, связанные с разработкой программного продукта.

Модель CMMI (Capability Maturity Model Integation) выбрана в Центре разработки ПО компании Motorola в качестве основы для поддержки процессов создания программного обеспечения. Требования одной из процессных областей модели Decision Analysis and Resolution (DAR) охватывают процессы принятия решений на основе формальных методик.

Процесс принятия решений на основе формальных методик

Безусловно, не каждая проблема требует проведения структурированного анализа — обычно использование формальных методик бывает обосновано, если затраты на процесс принятия решения меньше стоимости последствий принятия неправильного решения. В соответствии с требованиями модели CMMI для процессной области Decision Analysis and Resolution (CMMI for Development, Version 1.2, Technical Report, CMU/SEI-2006-TR-008) любой структурированный процесс принятия решений включает в себя:

  • определение проблемы и критериев принятия решения;
  • выбор методики принятия решений;
  • выявление и анализ альтернативных решений;
  • выбор решения;
  • информирование о результатах анализа.

Определение проблемы и критериев принятия решения

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

Дополнительно можно рассмотреть следующие критерии обоснованности применения формальных методик:

  • стоимость проблемы (последствия принятия неправильного решения) превышает десятую часть бюджета проекта;
  • вероятность возникновения проблемы вследствие принятия неправильного решения составляет более 50%.

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

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

Выбор методики принятия решений

Выбор методики зависит от многих факторов, среди которых можно выделить следующие:

  • признание методики заинтересованными сторонами, вовлеченными в принятие, одобрение и реализацию решения;
  • наличие экспертизы в предметной области, знание методик принятия решений;
  • стоимость применения методики;
  • временные ограничения.

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

Выявление и анализ альтернативных решений

Старайтесь предлагать как можно больше идей альтернативных решений — лучше откинуть неподходящее решение на этапе анализа, чем упустить выгоду из-за малого количества рассмотренных вариантов. Для этого предлагается проводить «мозговые штурмы» с проектной командой, интервьюировать заказчиков и использовать методики ТРИЗ (Теория Решения Изобретательских Задач). Тщательное изучение проблемы, критериев и целей является эффективным началом в выявлении альтернативных решений.

Подготовка нескольких альтернатив на ранних стадиях процесса позволяет повысить вероятность принятия адекватного решения с четким пониманием всех возможных последствий и рисков.

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

Результат анализа покажет, насколько каждый из выбранных критериев реализован в каждой из рассмотренных альтернатив.

Выбор решения

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

На наш взгляд, допустимым является проведение анализа с использованием другой методики, однако это может быть сопряжено со значительными дополнительными расходами. Делая окончательный выбор, основывайтесь на анализе как краткосрочных, так и долгосрочных перспектив решения проблемы и последствий принятия решения.

Информирование о результатах

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

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

Обзор методик

Существует множество формальных методик принятия решения, от простого голосования до применения структурированных подходов. Каждая из них имеет свои сильные и слабые стороны, и выбор конкретной методики зависит как от решаемой задачи, так и от стадии, на которой находится проект в данный момент времени. Немаловажную роль играет обучение людей, вовлекаемых в процесс принятия решений. Считается, что «чем проще методика, тем лучше», но с другой стороны, решение комплексных проблем требует применения методик, позволяющих всесторонне оценить предложения. Хорошо себя зарекомендовали следующие методики, позволяющие реализовать DAR-процесс:

  • анализ рынка (Trade Analysis);
  • аддитивная методика с использованием весов (Basic Additive Weighting);
  • командный консенсус (Team Consensus);
  • дерево решений (Decision Tree).

Анализ рынка — метод оценки альтернатив на основе использования равнозначных критериев, при этом все критерии делятся на «обязательные» (да/нет) и «желательные». Если альтернативное предложение не выполняет требования хотя бы одного из «обязательных» критериев, эта альтернатива автоматически убирается из рассмотрения. Оставшиеся варианты оцениваются по «желательным» критериям, и предложение, набравшее наибольшее количество баллов, «побеждает». Плюсом этой методики является ее простота, однако без определения важности критериев выбора может сложиться ситуация, когда решение будет принято на основании второстепенных критериев.

Аддитивная методика с использованием весов подразумевает добавление весовых коэффициентов выбранным критериям. Наряду с анализом рынка аддитивная методика относится к мультикритериальным методам принятия решений и включает в себя следующие шаги:

  • выбор критериев оценки;
  • выбор оцениваемых альтернатив (Wj);
  • ранжирование относительной важности каждого критерия (весовой коэффициент);
  • оценка критерия для альтернатив (Xij);
  • подсчет аддитивности Di=∑Wj*Xij.

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

Цель консенсуса — принять решение, которое отражает мнение всех участников. Каждый член группы играет равноправную активную роль в принятии решения. Метод консенсуса берет за основу не правило большинства, а достижение согласия всех участников в том, что выбранное решение является наиболее приемлемым для группы. Такая методика требует больше времени, активного участия членов группы, дополнительных навыков коммуникации (умение слушать, разрешать конфликты, вести дискуссию) и творческого мышления. К техникам достижения консенсуса относятся «мозговой штурм» и мультиголосование. Мультиголосование — метод выбора наиболее важных опций из списка с помощью серии голосований, при каждом туре которых происходит сокращение количества опций. Мультиголосование можно применять после «мозгового штурма» для сокращения предложений для обсуждения. Шаги мультиголосования:

1) составление пронумерованного списка предложений;

2) объединение похожих пунктов, перенумерация списка;

3) все участники подают свои голоса за пункты, которые они считают приоритетными. Количество пунктов, за которые можно голосовать, должно быть ограничено: как правило, не больше, чем треть списка;

4) по окончании голосования производится подсчет количества голосов для каждого пункта;

5) для сокращения списка убираются пункты, набравшие наименьшее количество голосов. Размер группы влияет на минимальное количество голосов для прохождения критерия. Так, для маленькой группы (не более пяти человек) убираются опции, набравшие один или два голоса, а в группе среднего размера (6-15 человек) — набравшие четыре и менее голосов;

6) повтор шагов 2-5 для оставшихся пунктов с сокращением их количества, пока не останутся одна или несколько приоритетных опций.

Дерево решений — метод, помогающий выбрать решение между несколькими направлениями действий. Методика состоит из следующих этапов.

  • Создание дерева решений. Дерево решений представляет собой граф, в корне которого лежит поставленная проблема. Каждый узел дерева — это многовариантное решение, которое надо принять и которое определяет, в какой узел осуществляется дальнейший переход. Результатом является путь от начального узла к конечному, состоящий из последовательности решений.
  • Оценка дерева решений. На этом этапе необходимо оценить каждый полученный результат по двум параметрам: приносимая выгода (в денежном или балловом эквиваленте) и вероятность реализации решения. Значение результата получается умножением выгоды результата на его вероятность. Дополнительно оценивается стоимость каждого узла решений.
  • Получение результата. Оптимальной является опция с наиболее выгодным результатом и с наименьшей стоимостью решения.

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

Применение формальных методик принятия решения

Методики принятия решения, используемые в Центре разработки ПО Motorola в Санкт-Петербурге, разнообразны, им присуща широта применения, и выбор того или иного подхода зависит от типа и сложности решаемой задачи.

Выбор жизненного цикла разработки

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

  • Каскадная модель. Проектные фазы и активности выполняются в определенном порядке. Модель применяется в проектах, где изначально ясны как объем работ, так и требования к продукту.
  • Модель прототипирования. Быстрая частичная реализация продукта для определения требований к продукту. Прототип помогает прояснить требования, проверить эффективность алгоритмов и согласовать интерфейсы с заказчиком или конечным пользователем. Модель применяется в проектах, где необходимо сократить неопределенность требований.
  • Инкрементальная модель. Продукт реализуется путем добавления к каждой последующей версии новой функциональности и всегда готов к использованию. Модель применяется в проектах, где требования к продукту известны, но предполагается, что функциональность продукта будет наращиваться.
  • Спиральная модель. Каждая итерация разработки программного продукта состоит из одинаковой последовательности шагов. С каждым витком спирали создается новая часть продукта или прорабатывается новый уровень совершенствования системы. Модель подходит для больших систем, когда требования неясны, а часть функциональности будет меняться по ходу проекта или высоки риски.

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

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

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

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

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

Выбор технического решения

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

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

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

Обычно критерии выбора альтернативных технических решений представляют собой набор атрибутов качества (quality attributes) — ключевых характеристик продукта, ожидаемых заказчиком и конечным пользователем системы. Атрибуты можно условно разделить на следующие категории: измеримые во время исполнения (доступность, функциональность, надежность, производительность, безопасность, удобство и простота использования); неизмеримые во время исполнения (контролируемость, сопровождаемость, возможность модификации, переносимость, возможность повторного использования, тестируемость, возможность переконфигурирования); бизнес-характеристики (стоимость разработки и сопровождения, прогнозируемое время жизни системы, время выхода продукта на рынок).

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

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

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

Формирование проектной команды. Критериями решения здесь могут выступать опыт, знания, личностные качества и навыки межличностного общения.

Александр Бабкин (Alexander.Babkin@motorola.com), Елена Беляева (Yelena.Belyayeva@motorola.com) — сотрудники Центра разработки программных продуктов компании Motorola (Санкт-Петербург).

Центр разработки ПО компании Motorola

Санкт-Петербургский центр разработки программных продуктов Motorola был открыт в 1997 году, став первым официальным представительством корпорации в городе. Центр ведет разработки по четырем основным направлениям:

  • Java-технологии;
  • программное обеспечение для телекоммуникаций;
  • решения и средства удаленного доступа;
  • мультимедийные решения и технологии.

С 1999 года Центр работает над сертификацией процесса разработки программного обеспечения на соответствие мировым стандартам. Основным в этой области является достижение Центром наивысшего, пятого уровня по модели SEI-CMM в 2001 году, первым в регионе EMEA, и по модели SEI-CMMI в 2004 году.

Инструментарий

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

Кроме того, широкое распространение получило инструментальное средство MindManager от компании Mindjet, позволяющее в режиме онлайн визуализировать процесс принятия решения, в частности, «мозговые штурмы» и другие производственные совещания. С помощью системы можно регистрировать результаты, систематизировать информацию, группировать и связывать между собой различные сущности (комментарии, действия, таблицы), расставлять приоритеты действиям и отслеживать их выполнение.