Agile Feature Driven Development для разработки программы по управлению материально-производственными запасами предприятия (часть 2)

3. Планирование разработки функциональных возможностей

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

4. Проектирование и итеративная разработка приложения

Реализация программного продукта ведется порционно, что отражено отдельными итерациями в плане разработке (табл. 3.1), это является особенностью всех гибких методов имплементации. Физическому старту разработки приложения предшествуют активности его проектирования. Следуя классическому подходу по подготовке архитектуры ИТ-решения [3], необходимо сначала описать процесс в модели TO-BE, далее построить структуру данных для хранения информации, связанной с выполнением бизнес-операций, затем проработать макет будущей программы и только после этого приступить к ее программированию.

Для разработки программного продукта по управлению МПЗ будут использоваться следующие инструменты и технологии: C#, WPF и MS SQL. Их комбинация предоставляет мощный инструментарий для создания приложения: язык программирования C# необходим для разработки бизнес-логики, технология WPF позволяет генерировать привлекательные и интерактивные пользовательские формы, а система управления базами данных MS SQL обеспечивает надежное хранение и управление данными.

4.1. 1-я итерация проектирования и разработки

4.1.1. Моделирование бизнес-процессов в модели TO-BE

Для демонстрации изменений, которое вносит разрабатываемое программное средство в бизнес-процесс регистрации МПЗ, необходимо его смоделировать в TO-BE. Описание данного процесса на 3-м уровне декомпозиции дано на рисунке 4.1.1. Как видно из рисунка, сохранение электронной карты МПЗ в базе данных исключает движение бумажных документов из одного отдела предприятия в другое.

Рис. 4.1.1. Процесс «Зарегистрировать МПЗ» в модели TO-BE на 3-м уровне декомпозиции с использованием нотации BPMN 2.0

Декомпозиция процесса заполнения электронной карты МПЗ представлена на рисунке 4.1.2, где изображена специфика ее формирования.

Рис. 4.1.2. Процесс «Заполнить электронную карту МПЗ» в модели TO-BE на 4-м уровне описания с использованием нотации BPMN 2.0

Финальная карта бизнес-процессов, демонстрирующая изменение модели предметной области в TO-BE, представлена на рисунке 4.1.3.

Рис. 4.1.3. Карта бизнес-процессов в модели TO-BE для 1-й итерации разработки

4.1.2. Проектирование структуры базы данных

Функциональные возможности, входящие в состав 1-й итерации разработки, предполагают взаимодействие с информацией: ее хранение и редактирование. Для этого проектируется архитектура данных, которая будет применяться в реализуемом программном продукте. Путем общения с заказчиком были выявлены следующие классы данных, необходимые для бизнес-процесса регистрации МПЗ (табл. 4.1.1).

4.1.3. Создание карты приложения

Одно из пользовательских требований к разрабатываемому программному средству – наличие интуитивно понятного интерфейса. Для обеспечения удобства навигации между различными функциональными возможностями, предполагается главная страница приложения. В рамках 1-й итерации разработки функционала для управления МПЗ предполагается программирование соответствующей формы пользовательского интерфейса. Здесь также формируется экран создания электронной карты МПЗ. Итоги моделирования будущей программы отражены в схеме приложения (рис. 4.1.4).

Рис. 4.1.4. Карта приложения для 1-й итерации разработки

4.1.4. Программная реализация функциональных возможностей

Составленная на этапе проектирования схема баз данных реализуется в СУБД MS SQL, обеспечивая хранение соответствующих классов данных. Техническая реализация таблицы данных, содержащей информации о МПЗ, представлена на рисунке 4.1.5.

Рис. 4.1.5. Таблица данных о МПЗ

Экранные формы, запрограммированные с помощью MPS и C# в ходе 1-й итерации разработки, представлены на рис. 4.1.6-4.1.8. На главной форме по управлению данными МПЗ содержится таблица с записями, присутствует функционал для поиска данных по атрибутам, а также доступны кнопки для создания новой записи и ее сохранения в базе данных.

Рис. 4.1.8. Новая запись в таблице МПЗ

4.2. 2-я итерация проектирования и разработки

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

Бизнес-процесс формирования списка брака в модели TO-BE с использованием нотации BPMN 2.0 дан на рис. 4.2.1, реестр всех бизнес-операций суммирован в карте процессов из рис. 4.2.2.

Рис. 4.2.1. Процесс «Сформировать список брака» в модели TO-BE на 4-м уровень декомпозиции с использованием BPMN 2.0

Рис. 4.2.2. Карта бизнес-процессов в модели TO-BE для 2-й итерации разработки

Результаты идентификации данных, необходимых для бизнес-процесса составления списка брака, даны в табл. 4.2.1, где атрибуты нормализованы до 3-й НФ [4]. Соответствующая ER-диаграмма приведена на рис. 4.2.3.

Рис. 4.2.3. ER-диаграмма данных для 2-й итерации разработки

Реализация функциональных возможностей, для которых описаны TO-BE бизнес-процессы (рис. 4.2.1-4.2.2) и спроектированы данные (рис. 4.2.3), ведется в программной разработке, модель пользовательского интерфейса которой дается на рис. 4.2.4.

Рис. 4.2.4. Карта приложения для 2-й итерации разработки

Результаты проделанной работы по моделированию процессов, данных и структуры приложения, находят свое отражение в разработанном программном приложении, копии экрана которого приводятся ниже (рис. 4.2.5-4.2.6): реализуется таблица баз данных и соответствующая ей пользовательская форма обработки.

Рис. 4.2.5. Результирующая таблица список брака

Полный текст статьи: https://corpinfosys.ru/archive/2023/issue-23/248-2023-23-agilefdd