Меню

Точное определение требований к решению методом исследовательского моделирования (xM) для исключения любых ошибок в приложениях после перехода к продуктивной эксплуатации

|

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

Одной из наиболее трудных (но при этом и самой фундаментальной) задачей проектных групп SAP является определение точных и выполнимых требований к решению для определенной бизнес-цели. Рассмотрим следующий пример: представьте, что требуется написать алгоритм для проверки наличия дублированных счетов-фактур на определенном этапе процесса, например, при следующем вводе данных или в течение выполнения ночного фонового задания. Сразу возникают следующие вопросы: что именно заставляет нас полагать, что один счетфактура идентичен другому? Считать ли два счета идентичными при простом совпадении данных заказчика и общего количества или необходимо проверить идентичность каждого отдельного поля? А если все данные “совпадают”, а последовательность строк – нет? Зависят ли эти критерии от компании, отдела или пользователя (очень часто!)? Какие еще возможные ситуации не были учтены или продуманы?

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

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

В этой статье рассматривается альтернативный, итеративный подход к процессу сбора требований/проектирования приложения, который называется исследовательское моделирование (eXploratory Modelling, xM). Он успешно применялся в рамках последних проектов SAP. Данный подход направлен на преодоление извечной коммуникационной пропасти между разработчиками и пользователями за счет более интенсивного взаимодействия с предполагаемыми (и будущими) конечными пользователями и сокращения циклов анализа/проектирования для обеспечения мгновенной обратной связи и внесения корректировок в проект. Широко известен метод использования HTML-макетов для визуализации статических функциональных возможностей и шагов процесса. Основная идея xM состоит в создании аналогичного функционального макета – внедренной функционирующей модели вместе с простым тестовым приложением – в случае сложных или неизвестных требований и его использовании в качестве основы для обсуждения с пользователями бизнес-процесса. Трудность при этом вызывает создание такой экспериментальной среды в рамках разумных усилий.

Внимание!

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

Оформите подписку sappro и получите полный доступ к материалам SAPPRO

У вас уже есть подписка?

Войти

Обсуждения Количество комментариев1

Комментарий от  

Антон Чиркунов

  |  12 июля 2010, 20:55

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