4. Типовая структура спецификации на разработку
Ссылка на 1-ю часть статьи. Завершив подготовительное концептуальное проектирование программы и идентифицировав стандартные таблицы по хранению данных в ERP-системе, приступаем к написанию функциональной спецификации. Содержание спецификации зависит от категории RICEF-разработки, однако можно выделить следующие типовые разделы документа:
- описание исходных бизнес-требований;
- модель TO-BE;
- допущения;
- концепция решения;
- логика взаимосвязи экранов, их полей и алгоритмов заполнения;
- сценарии функционально-модульного тестирования;
- роли и полномочия.
Бизнес-требования, описание процесса с учетом текущей разработки в модели TO-BE, а также концепция решения необходимы для того, чтобы пользователи могли однозначно идентифицировать исходные потребности в текущей разработке и ознакомиться с верхнеуровневым решением, не вдаваясь в технические подробности. Последнее весьма существенно, так как одним из подтверждающих документа спецификации всегда является бизнес-представитель, далекий от таблиц баз данных, языков программирования и программной архитектуры.
Раздел допущений введен неслучайно. Общий подход к обработке требований заключается в том, что все открытые вопросы и неоднозначности должны быть закрыты и максимально детально уточнены бизнес-пользователями или внешней организацией. К сожалению, это не всегда достижимо, что не отменяет исходные сроки подготовки спецификации. В подобных случаях используются допущения.
Определение 10. Допущение – это предположение или гипотеза, выдвижение которых равнозначно самостоятельному ответу на открытый вопрос, что позволяет снизить неопределенность в процессе имплементации КИС.
Рис. 23. Пример использования допущений для исключения неопределённостей
Следуя изначально продуманной концепции решения, описываются экраны пользовательской программы и логика перехода между ними, кроме того поля, кнопки, функции и подэкраны каждого экрана, а также алгоритмы обработки данных, что обсуждалось ранее в п.3.2-3.3. Детализация указанных элементов – самая трудоемкая задача процесса подготовки спецификации, требующая львиную долю плановых трудозатрат.
Рис. 24. Пример структуры спецификации для разработки C-программы по обработке данных
Проведение испытания разработанной на основе спецификации программы осуществляется в среде разработки путем функционально-модульного тестирования. Сценарии тестирования, дополненные тестовыми данными, приводятся в одноименном разделе. Документирование и отслеживание последующих видов испытаний: системного, интеграционного и непрерывного тестирований, ведется отдельно, преимущественно в программной системе ALM (Application Lifecycle Management) от компании HP.
Реализованные с нуля отчеты, программы, формуляры и интерфейсы должны быть добавлены в технические роли для возможности использования пользователями в ERP-системе. Присвоение пары «программа – роль» описывается в разделе ролей и полномочий. На рисунке ниже даны несколько примеров содержания спецификации на разработку для получения более полной картины возможных способов наполнения документа.
5. Особенности проектирования программ и их отражение в спецификации на примере SAP ERP
Типовая структура спецификации применяется для моделирования и последующей реализации любой RICEF-разработки. Введенные принципы проектирования программ так же находят свое отражение в документе спецификации. Уточним их до уровня функциональных требований, используя следующую шкалу приоритетов: высокий, средний и низкий. Если принципу соответствует высокий приоритет, значит его несоблюдение не позволит перенести программную разработку в продуктивную ERP-систему, средний – следование принципу обеспечивает унификацию и генерализацию решения, его игнорирование в будущем приведет к ошибке, что потребует доработки программы, и, наконец, низкий приоритет носит рекомендательный характер, относящийся к категории «бантики» (или «Nice to Have» в англоязычной литературе). Результаты детализации принципов до функциональных требований и эмпирическая оценка их приоритетов рассмотрена в пунктах ниже.
5.1. Проектирование всех видов RICEF-разработок
Выделим функциональные требования, относящиеся ко всем видам RICEF-разработок (табл.1). Высокоприоритетными требованиями являются: использование утвержденных правил наименования объектов разработки, а также вынесение константных переменных в отдельный модуль. Первое требование определяет технический регламент наименования переменных, функций, подпрограмм, объектов, структур и прочих составляющих разрабатываемого приложения (Naming Convention, соглашение по наименованию); второе задает порядок ведения константных переменных для программных разработок, как известно, запрещено их явное указание в программном коде. Способы обработки константных значений приведены на рис.25 в привязке к системе SAP ERP.
Полный текст статьи: https://corpinfosys.ru/archive/issue-8/69-2019-8-functionalspec
