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

«Agile-ра­зра­бо­тки для SAP: освойте методику Scrum!»
Александр Биличенко:
интересная статья, но на мой взгляд слишком обременена ежедневными совещаниями. это большие затраты времени
«Новая концепция ра­сши­ре­ний как метод со­ве­рше­нство­ва­ния программ SAP без их мо­ди­фи­ка­ции»
Дмитрий Воронин:
Отличная статья, но желательно, чтобы в статье использовались примеры с реально существующими расширениями в системе SAP.
«Создание объе­ктно­-о­ри­е­нти­ро­ва­нных ко­рпо­ра­ти­вных при­ло­же­ний и отделение доступа к базе данных от при­кла­дной логики при помощи сервисов объектов ABAP»
Дмитрий Воронин:
Следовало бы добавить в статью пример небольшого приложения, которое можно было бы скопировать и использовать как стартовый плацдарм для дальнейшего изучения.

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

Хайнц Роггенкемпер
Рольф Эрет
Андреас Тенне
1548
1

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

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

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

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

Внимание!

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

Вы хотели бы увидеть полную версию статьи?

Если вы являетесь подписчиком журнала SAP Professional Journal, пожалуйста, введите в правом верхнем углу логин и пароль.

Если вы хотите подписаться на журнала SAP Professional Journal, пожалуйста, обратитесь в редакцию или сделайте заказ на сайте.

Правила получения тестового доступа к статьям SAP Professional Journal

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

Антон Чиркунов (Рейтинг: 14) 20:55, 12 июля 2010

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

Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП» Copyright © 2010 Wellesley Information Services. All rights reserved.