Программный проект: соотносим теорию с практикой

Здесь мы попытаемся пройтись по реальному проекту (создание конфигурации «Грузовая проходная» на платформе 1С 7.7. «с нуля») по цепочке «Стратегия — Анализ — Проектирование — Реализация — Тестирование». Проект «внутренний» (разработка собственными силами), поэтому проблемы Внедрения (customer acceptance tests) и Эксплуатации/поддержки здесь неинтересны. Мало того, руководитель проекта, проектировщики, разработчики и эксплуатационники — все это один человек.

Указанные этапы жизненного цикла соответствуют таковым из моей статьи «Хаотическая автоматизация». Но вначале, разумеется, постановка задачи. Итак,

Цели проекта.

1. Обеспечить автоматизированный контроль соответствия количества продукции, вывозимой через грузовую проходную, количеству продукции, оформленной бухгалтерскими документами для отгрузки.
2. Обеспечить автоматизированный учет основных технологических материалов (уголь, известняк), завозимых на территорию завода.

Задачи проекта.

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

 

Таковы были «хотелки» безопасников. А еще были платформенные автомобильные весы.

Стратегия.

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

 

Итак, на этом этапе фиксируем ограничения. Кроме вышеупомянутых «хотелок» были и другие, наподобие возможности автоматической передачи требуемого количества мест (мешков) контроллеру погрузочной машины, управления шлагбаумами, автораспознавания номера автомобиля, автопроведение бухгалтерских документов по факту отгрузки… Взглянув на предварительный бюджет в части покупки оборудования, ПО и услуг внешних организаций, руководство платить столько не согласилось. Да и запрошенную мной сумму за разработку конфигурации (в размере 1/3 от рыночного аналога (http://www.npfsimplex.ru/sheben/calculator.html) тоже посчитали слишком большой.

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

Анализ.

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

 

Я бы в данном случае вместо «бизнес-процессы» применил термин «технологические цепочки». Начало технологической цепочки «Вывоз» — момент получения в бухгалтерии документов на отгрузку продукции (накладная и материальный пропуск). Именно в этот момент должна быть сформирована некая новая сущность — идентифицируемая совокупность атрибутов: автомобиля, получателя груза (водителя), и разрешенного количества груза. В качестве идентифицирующего атрибута решили использовать простейшие смарт-карты — без функции записи, позволяющие только считывать номер. Поскольку речь идет об 1С, в качестве представителя данной сущности, очевидно, будет выступать Документ.

Карта выдается бухгалтером при оформлении отгрузочных документов — с указанием в них номера выданной карты, — либо диспетчером автопарка — вместе с нарядом на завоз технологических материалов. Рабочие места бухгалтера и диспетчера оснащаются считывателями карт для исключения ошибочной «привязки». Информация о реквизитах накладной записывается в dbf-файл, расположенный в общей для бухгалтерии и системы контроля папке. Процесс чтения данных из этого файла запускается каждый раз при считывании на проходной карты, предъявляемой «сторонним» водителем. После каждого чтения файл очищается. Если считанная на проходной карта находится в перечне, полученном из бухгалтерии, будем создавать в системе Документ на вывоз.

Диспетчер автопарка работает в базе данных системы контроля, поэтому сведения о нарядах на завоз (Документах) доступны в системе непосредственно. На нем цепочка «Завоз» начинается и завершается, а в промежутке происходит взвешивание.

Непосредственно у въездных ворот располагаются платформенные электронные весы, которые могут находиться в одном из 4-х состояний: стабильный нулевой вес, стабильный ненулевой вес, нестабильный вес, неготовность (авария). Периодически опрашивая контроллер весов, мы можем по изменению состояния отследить, когда требуется фиксация веса, а при предъявлением водителем карты определить, куда (в какой реквизит какого документа) этот вес должен быть записан. Вид карты (Ввоз/Вывоз) и направление движения однозначно определяют вариант взвешивания (брутто на въезде, тара на въезде, брутто на выезде или тара на выезде). Таким образом, оператор на весах по-видимому, не потребуется.

Завершается технологическая цепочка «Вывоз» при сдаче водителем смарт-карты контролеру на проходной при выезде. При этом контролер фиксирует (проверяет) соответствие реального веса вывозимой продукции весу по выписанным документам. Правда, пока неясно, что делать при несоответствии.

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

Проектирование.

Из множества задач этапа проектирования выделим три ключевые:

• Проверка полноты результатов анализа
• Использование продуктов третьих разработчиков и взаимодействие с ними
• Отображение функций системы на ее модули

 

На выходе этапа проектирования должна быть получена модель функций и модель данных. На самом деле, этап проектирования — это этап синтеза системы.

 

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

Что касается продуктов третьих разработчиков, здесь в качестве таковых выступают бухгалтерская конфигурация 1С 7.7., требующая дополнения механизмом выдачи карт, и драйвер электронных весов. Для используемых весов фирмы «Метра» производитель предлагает драйвер DevNet.drv, вполне 1С-совместимый и ранее у нас апробированный в автоматизированной системе учета заготовки сырья. Он позволяет подключить через COM-порт до 32 весовых контроллеров и/или информационных табло.

Модули системы — это, на верхнем уровне, рабочие места технологической цепочки: «Бухгалтерия», «Автопарк», «Проходная», «Весы». Функция бухгалтерии — «привязка» к карте реквизитов отгрузки и формирование записей в файле обмена. На проходной происходит выбор записи, соответствующей предъявленной карте, создание документа отгрузки в БД, и, после заполнения реквизитов (Тара-Брутто-Нетто) документа, освобождение карты для повторного использования. Ввозными картами манипулирует диспетчер автопарка: «привязывает» карту к наряду (вновь создаваемому документу) и, после сдачи водителем карты в конце дня, закрывает заполненный наряд, тем самым освобождая карту.

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

Реализация.

Основная задача разработчиков состоит в том, чтобы уяснить спецификацию: проектировщик написал, что надо сделать, разработчик определяет, как это сделать.

 

Итак, я перестал быть проектировщиком и перешел в статус разработчика. Первое, что надо уяснить — сколько имеется мест, где проектировщик влез в прерогативу разработчика, т.е. указал механизм реализации (как), и следует ли отвергнуть его идеи, либо ими воспользоваться. Таких мест насчитывается два: связь через файл .dbf и отображение «сущности» грузоперевозчика в виде документа. В первом случае в пользу .dbf (по сравнению, например, с .txt) говорит то обстоятельство, что объект XBase позволяет проанализировать причину неудачи при манипуляциях с файлом, что даст возможность избежать коллизий при одновременном обращении к файлу с двух рабочих мест (что, впрочем, весьма маловероятное событие). Так что здесь я соглашусь с проектировщиком.

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

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

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

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

Бухгалтерская конфигурация в русле методики неразрушающего конфигурирования (это здесь) только дополняется перечнем (Справочником) «вывозных» смарт-карт и внешней обработкой их чтения. Кроме этого, подменяются процедуры печати отгрузочных документов (ВПФ) — в них добавляется запрос на выдачу смарт-карты, печать номера выданной карты на накладной и запись реквизитов в dbf-файл.

Далее — достаточно простое кодирование, сводящееся к подгонке готовых «узлов», ранее обкатанных в других системах (и частично опубликованных на Инфостарте), друг к другу.

Тестирование.

По меньшей мере (согласно ГОСТу), в Программе и методике испытаний создаваемой системы должен быть описан приемосдаточный (комплексный) тест.

 

Так-то оно так. Только кто ж будет писать эту самую Программу и методику забесплатно. Будет, конечно два теста, по количеству технологических цепочек — простое формирование документов отгрузка (завоза) прохождение их через автозаполнение на весах (во втором случае — несколько строк) и закрытие (освобождение карты). Результаты тестов будут видны в базе как в виде наличия и состояния Документов, так и в виде содержимого таблицы на рабочей форме проходной. Вот и все тестирование…

 

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

Резюме.

Методика может быть хорошей или не очень. Но наличие методики всегда лучше, чем ее отсутствие.

 

Разумеется, для столь небольшого проекта, целиком «помещающегося» в голове, можно обойтись и без вышеописанных рассуждений. Это всего лишь иллюстрация одной из методик, отнюдь не единственной. Тем не менее, такой (методический!) образ действий при разработке позволяет избежать самых типичных ошибок и «излишеств», вроде дублирования функций, внесения в систему несуществующих «сущностей», неверных технических решений, навязанных проектировщиком и/или заказчиком.

Честно говоря, данный проект вначале развивался «с точки зрения банальной эрудиции» и добрался таким образом до автономных тестов. Потом я решил провести вышеописанный эксперимент. И применение описанного методического подхода заставило меня многое изменить. Конфигурация стала стройней, прозрачней, да и объем кода сократился.

1 сентября ожидается начало «полевых испытаний». По результатам «обкатки» я намереваюсь конфигурацию опубликовать. Так что не прощаюсь…