Формирование универсальных требований к пользовательским программам при подготовке спецификации на разработку

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

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

Несмотря ни на что, приступаем к подготовке многострадальной спецификации. Первая сложность, с которой сталкиваемся, – это реалистичная оценка трудозатрат на формирование документа спецификации. Допустим, как-то оценили, что дальше? Описываем требования заказчика и готовим тестовые данные. Все? Разработка выполнена. Тестируем «2 + 2 = 4», верно. А вот сколько будет «2 + 3»? Такого задания в спецификации описано не было. Тогда в лучшем случае получим равенство «2 + 3 = 4». Сложность вторая – доскональное описание алгоритмов, проверок и данных, пусть даже вполне очевидных. Исправили, доработали. Тестируем, все верно, «2 + 3 = 5». А все ли пользователи имеют полномочия на выполнение суммирования? Это третья, но не последняя сложность. Знакомо? Таким образом, приведенный выше пример иллюстрирует необходимость формирования универсальных требований к разработкам без акцентирования внимания на характере прикладной задачи. Предлагается применение обобщенной структуры описания программ. Полный текст статьи доступен по ссылке: http://stepanovd.com/article_2014_4_design.html?lang=RU.