Разработка модуля внешней обработки для «1С Предприятие 8.2. Управление торговлей 10. 3»

РЕФЕРАТ информационный интерфейс приложение модуль Дипломный проект содержит листов текста пояснительной записки, рисунок, приложение, источников литературы.

ИНФОРМАЦИОННАЯ СИСТЕМА, ТРЕБОВАНИЯ, МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА, МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ, МОДЕЛИРОВАНИЕ, ПРОЕКТИРОВАНИЕ, РЕАЛИЗАЦИЯ, 1С ПРЕДПРИЯТИЕ, БАЗА ДАННЫХ, ТЕСТИРОВАНИЕ, ФИЗИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ СИСТЕМЫ, ЛОГИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ СИСТЕМЫ, СКД, АНАЛИЗ ДАННЫХ.

Темой дипломного проекта является «Разработка программного модуля продажи по товарным матрицам для 1С. Управление торговлей 8.2 (на примере ООО „Крепежная Компания“)».

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

В проекте реализован программный модуль «продажи по товарным матрицам», ускоряющий процесс анализа продаж товаров.

Результаты работы могут быть применены в ООО «Крепежная Компания» для повышения товарооборота и увеличение прибыли.

ABSTRACT

Thesis project contains sheets of the text of the explanatory note, Figures, application, sources of literature.

INFORMATION SYSTEM REQUIREMENTS life cycle model, the methodology for design, modeling, design, implementation, 1C, DATABASE TESTING PHYSICAL PRESENTATION SYSTEM LOGICAL VIEW SYSTEMS, ACS data analysis.

The theme of the graduation project is «Development of the software module sales by product matrices for trade 1S. Upravlenie 8.2 (for example, Ltd.» Krepejnaya Kompaniya")."

The data sources for this diploma project were books, periodicals, electronic resources used as a theoretical basis for the problem. Thus, the literary sources were used as practical tools for implementation of the project.

The project implemented a software module «Sales by product matrices», accelerating the process of analyzing sales of goods.

The results can be applied to the Company «Krepejnaya Kompaniya «to increase turnover and profit increase.

В наш век компьютеризации многие крупные и малые предприятия задумываются об автоматизации рабочих процессов. Если раньше автоматизация бизнеса, как правило, волновала лишь крупные предприятия, то сегодня автоматизация малого бизнеса — такое же обычное явления. Автоматизация бизнес процессов позволяет значительным образом снижать расходы, оптимизировать рабочие процессы, убирать ненужную рабочую силу и переводить ее на более необходимые позиции. Системы автоматизации бизнеса позволяют сделать производство продукции более оптимальным, а также вести учет и прочие процессы в бизнес среде на автоматической, а не ручной основе. Это также служит причиной меньших накладок и ошибок, сведения на нет человеческого фактора и имеет еще массу преимуществ. Кроме того, автоматизация бизнеса объединяет силы различных отделов и делает работу компании более эффективной.

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

Целью данной работы является разработка модуля внешней обработки для «1С Предприятие 8.2. Управление торговлей 10.3»

Задачи работы — сбор требований, проектирование внешней обработки, ее тестирование и внедрение.

1. РАЗРАБОТКА ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

1.1 Анализ существующих решений по автоматизации предметной области

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

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

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

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

В настоящий момент у нас на рынке представлен целый ряд программ автоматизации таких как:

— 1С Предприятие;

— Штрих — М;

— SET Retail 5;

— Shelter;

— R-Keeper.

1.2 Выбор методологии проектирования информационной системы

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

Рисунок 1 — Фазы разработки решения 1С

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

1.3 Анализ предметной области

Компания «Крепежная Компания» активно представлена на рынке Южного Федерального округа с 2001 года. В настоящее время является одним из крупнейших поставщиков крепежных материалов строительного и конструкционного крепежа. Продукция, представленная нашей компанией, выпускается на отечественных и зарубежных заводах, прошедших стандарты ISO 9002, QS 9000 и имеет все необходимые сертификаты соответствия, подтверждающие высокое качество товаров.

Компания имеет следующую организационную структуру, рисунок 2:

Рисунок 2 — Организационная структура Стратегическая цель. Стать первыми в области строительства и технического комплектования, крепежом, объектов коммерческого и промышленного назначения.

Ценности компании. Деятельность ЦК «Крепежная Компания» базируется на ценностях, являющихся основой для строительной и технической деятельности во всем мире, это:

— профессиональная компетентность сотрудников ЦК «Крепежная Компания»;

— кооперация со специалистами по направлениям деятельности;

— выполнение взятых на себя обязательств;

— «Крепежная Компания» соблюдает требования руководящих документов, выработанных органами исполнительной власти Российской Федерации.

Структурная диаграмма процесса формирования отчета представлена на рисунках 3−7.

Рисунок 3 — Контекстная диаграмма Рисунок 4 — Декомпозиция работы «Подготовка отчета»

Рисунок 5 — Декомпозиция работы «Выбор варианта отчета»

Рисунок 6 — Декомпозиция работы «Подготовка данных»

Рисунок 7 — Декомпозиция работы «Заполнение формы отчета»

Рассмотрим возможности конфигурации 1С: Управление торговлей в области формирования отчетов для руководителя бизнеса.

В «1С:Управление торговлей 8» реализована система отчетов, представляющих собой мощное и гибкое средство для анализа всех аспектов торговой деятельности и товарооборота предприятия. Список отчетов сгруппирован по их назначению: Продажи, Закупки, Запасы (склад), Денежные средства и т. д. Например, в группе «Запасы (склад) «представлены отчеты, которые позволяют посмотреть остатки на складах, оценить остатки товаров в ценах компании, провести анализ оборачиваемости товаров, определить остатки товаров, находящиеся на реализации, провести ABC и XYZ — анализ товаров.

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

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

1.4 Сбор требований

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

Требования — это описание необходимых или желаемых свойств продукта.

На этапе сбора требований основная работа ведется с заказчиком системы и её будущими пользователями. Цель этапа — точно определить функции продукта и способы его интеграции в существующие процессы.

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

Существуют несколько способов сбора информации — это интервью, семинары и анкеты.

Интервью — наиболее распространенная форма обследования. Эффективность данного способа зависит в основном от степени подготовленности аналитика.

В таблице 1.1 приведены вопросы и ответы из интервью с пользователями обработки.

Таблица 1.1 — Сбор требований способом «интервью»

Таблица 1.1 — Сбор требований способом «интервью» продолжение

1.5 Анализ и моделирование требований

IDEF — методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.

IDEF — методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности — ICAM, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между всеми специалистами — участниками программы ICAM. После опубликования стандарта он был успешно применен в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов. Более того, собственно с широким применением IDEF (и предшествующей методологии — SADT) и связано возникновение основных идей популярного ныне понятия — BPR (бизнес-процесс реинжиниринг).

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

Рисунок 9 — Декомпозиция работы «Заполнение формы отчета»

1.6 Аттестация требований

После сбора требований они были зафиксированные в Техническом Задании. Техническое Задание приведено в приложении А.

2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

2.1 Архитектурное проектирование

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

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

Преимущества:

1. Если вы работаете в большой конфигурации, то сохранение маленького изменения и последующий запуск предприятия займет 3−10 минут в зависимости от размера конфигурации и мощности компьютера. Сохранение внешней обработки и открытие ее в предприятии на той же конфигурации и компьютере всегда будет занимать пару секунд;

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

3. В базе, в которой работает много пользователей, бывает очень сложно найти момент для того чтобы отключить всех пользователей и сделать изменения, а ошибка в каком-то отчете уже найдена и требует срочного исправления. Можно сохранить отчет как внешнюю обработку, внести в нее нужные изменения и отдать пользователям. А потом не спеша в удобное время вставить внешнюю обработку на замену неправильного отчета;

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

К недостаткам можно отнести то, что внешняя обработка не влияет на структуру базы, с помощью внешней обработки нельзя создать новый документ или справочник;

2.2 Проектирование пользовательского интерфейса

Интерфейс пользователя (UI) — это часть программы, которая находится на виду у пользователя и призвана обеспечивать отображение данных, управление или диалог с пользователем. Графический интерфейс пользователя (ГИП), графический пользовательский интерфейс (ГПИ) — разновидность пользовательского интерфейса, в котором элементы интерфейса (меню, кнопки, значки, списки и т. п.), представленные пользователю на дисплее, исполнены в виде графических изображений.

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

Рабочее окно внешней обработки показано на рисунке 10, оно состоит из верхнего меню и поля вывода отчета.

Рисунок 10 — Рабочее окно внешней обработки

На рисунке 11 показано окно настроек отчета.

Рисунок 11 — Окно настроек

Окно выбора вида построения диаграмм показано на рисунке 12.

Рисунок 12 — Окно выбора вида отчета

2.3 Обоснование выбора платформы создания информационной системы

" 1С: Управление торговлей 8″ — это современный инструмент для повышения эффективности бизнеса торгового предприятия.

" 1С: Управление торговлей 8″ позволяет в комплексе автоматизировать задачи оперативного и управленческого учета, анализа и планирования торговых операций, обеспечивая тем самым эффективное управление современным торговым предприятием (рисунок 13).

Рисунок 13 — Комплекс 1С

" 1С: Управление торговлей 8″ автоматизирует следующие направления хозяйственной деятельности:

— управление отношениями с клиентами;

— управление правилами продаж;

— управление процессами продаж;

— управление торговыми представителями;

— управление запасами;

— управление закупками;

— управление складом;

— управление финансами.

контроль и анализ целевых показателей деятельности предприятия.

В программе могут регистрироваться как уже совершенные, так и еще только планируемые хозяйственные операции. «1С:Управление торговлей 8» автоматизирует оформление практически всех первичных документов торгового и складского учета, а также документов движения денежных средств.

" 1С: Управление торговлей 8″ рассчитана на любые виды торговых операций. Реализованы функции учета — от ведения справочников и ввода первичных документов до получения различных аналитических отчетов.

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

" 1С: Предприятие 8″ предоставляет вам отвечающий самым современным стандартам комплекс инструментальных средств и технологий для разработки, модификации, администрирования и сопровождения корпоративной информационной системы. Все эти средства входят в поставку тиражных продуктов «1С:Предприятия 8». Без дополнительных затрат пользователь получает точно такие же инструменты, какие используют разработчики фирмы «1С». В результате установленная на предприятии система не будет «черным ящиком». Опыт показывает, что большинству системных администраторов и специалистов по автоматизации достаточно нескольких дней, чтобы освоить принципы построения решений «1С:Предприятия» — после этого система может не только сопровождаться, но и быть адаптирована в соответствии с потребностями своих организаций. Немаловажно и то, что пользователь сможет стать участником профессионального сообщества специалистов по «1С:Предприятию», получить поддержку при освоении системы, использовать возможность разностороннего общения и обмена опытом с многочисленными пользователями. Реальная открытость системы и легкость ее адаптации, широкие возможности масштабирования и интеграции, простота и удобство администрирования и поддержки — все это позволяет тратить минимум усилий на решение «низкоуровневых» технологических вопросов и сконцентрироваться на содержательных, творческих задачах автоматизации бизнес-процессов предприятия.

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

Итак, комплекс технических средств для функционирования данной обработки должен отвечать следующим минимальным системным требованиям (они такие же как и минимальные системные требования для самого комплекса 1С):

— операционная система: MS WindowsXP/Server 2003;

— процессор IntelPentium2000 МГц и выше;

— оперативная память 512 Мбайт и выше (рекомендуется 1Гбайт);

— жесткий диск (при установке используется около 1Гбайт);

— устройство чтения компакт дисков;

— USB-порт;

— SVGA дисплей.

2.4 Проектирование модулей Так как обработка создается для платформы «1С Предприятие», то она будет содержать следующие модули определенные платформой 1С Предприятие 8.2:

— модуль объекта;

— модуль формы;

— модуль менеджера объекта.

У многих объектов конфигурации (справочники, документы и т. д.) существует модуль объекта. В него можно вводить стандартные события, такие как создание нового элемента справочника, запись нового объекта, удаление, обработка проведения документа и т. д. Событие записи существует и в модуле формы (возникает в процессе интерактивной записи, когда пользователь нажимает на кнопку «записать») и в модуле объекта.

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

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

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

Структура управляемой формы содержит раздел описания переменных, раздел процедур и функций и раздел основной программы (выполняется в момент инициализации формы). К стандартным событиям формы можем обратиться через список процедур и функций (Ctrl+Alt+P) либо в палитре свойств самой формы. Так же в управляемой форме можно обработать событие записи элемента (это событие присутствует только для объектов: справочников, документов).

Модуль менеджера появился только в 1С 8.2,существует у многих объектов конфигурации. Основное предназначение модуля менеджера объекта это переопределить стандартное событие «ОбработкаПолученияДанныхВыбора».

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

3. РЕАЛИЗАЦИЯ И АТТЕСТАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Реализация приложения

Реализация программного обеспечения — это процесс перевода системной спецификации в работоспособную систему. Результатом реализации приложения является работоспособная информационная система.

Разработка набора элементов информационной системы осуществляется в едином рабочем пространстве. На рисунке 14 показана структура внешнего отчета.

Рисунок 14 — Система классов информационной системы В качестве основных инструментов для разработки внешнего отчета использовались:

— макет «Схема компоновки данных» в «1С Предприятие 8.2». Данный макет присущ отчетам, рисунок 15;

— средства конфигурирования платформы «1С Предприятие 8.2».

Рисунок 15 — Среда разработки «Схемы компоновки данных»

После создания нового внешнего отчета приступаем к созданию новой схемы компоновки данных (рисунок 16).

Рисунок 15 — Создание новой схемы компоновки данных Перейдя в «Конструктор схемы компоновки данных» приступаем к созданию нового набора данных — запрос (рисунок 17).

Рисунок 17 — Создание нового набора данных — запрос После добавления и настройки всех необходимых регистров, переходим к добавлению ресурсов (рисунок 18).

Рисунок 18 — Добавление ресурсов После настройки выбранных полей для детальных записей переходим к настройке параметров и написанию кода (рисунок 19).

Рисунок 19 — Фрагмент кода запроса

На фрагменте кода, представленном на рисунке 20 выполняется выбор данных по матрицам контрагентов из регистров накопления и ПродажиОбороты.

Рисунок 20 — Фрагмент кода Выбора данных После проведения окончательных настроек регистров и корректировки кодов запроса отчет практически готов, остается создать интерфейс рабочего окна. Рабочий интерфейс представлен на рисунке 21.

Рисунок 21 — Рабочий интерфейс

3.2 Взаимодействие приложения с источниками данных

Разработка прикладных решений в системе «1С:Предприятие» ведется в терминах объектов метаданных. Благодаря этому разработчик избавлен от необходимости вникать в то, каким образом данные того или иного объекта будут храниться в той или иной базе данных. Система самостоятельно создает необходимые структуры данных и работает с ними.

Кроме удобства разработки, такой подход гарантирует единообразную работу с создаваемыми структурами данных, т. к. за все операции с данными на уровне СУБД отвечает сама система. В частности, это позволяет в значительной мере гарантировать целостность и непротиворечивость данных, хранимых в базе данных.

Однако в редких ситуациях разработчику или администратору информационных баз «1С:Предприятия» все же может потребоваться информация о расположении данных, используемых системой. При этом нужно отдавать себе отчет в том, что такая информация может быть использована только для понимания расположения и состава данных, используемых системой. Непосредственная работа с данными должна выполняться исключительно средствами «1С:Предприятия». Все данные, которые использует система «1С:Предприятие», можно условно разделить на 5 групп в соответствии с их назначением и значимостью.

Данные информационной базы:

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

Данные хранилища конфигурации:

Хранилище конфигурации содержит текущую конфигурацию и историю ее разработки при использовании в конфигураторе средств групповой разработки. При разработке конфигурации эта информация также является жизненно важной.

Данные журнала регистрации:

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

Вспомогательные данные:

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

Временные данные:

Эти данные использует приложение «1С:Предприятия» для служебных целей. Они актуальны только в пределах одного сеанса работы и после его завершения уничтожаются.

Данные, которые определяют логику функционирования системы на базе «1С:Предприятия», относятся к информационной базе. Хранение информационной базы осуществляется в базе данных в виде набора таблиц. Для этого «1С:Предприятие 8» может использовать одну из пяти систем управления базами данных (СУБД): Встроенную в «1С:Предприятие 8» (файловый вариант информационной базы). В этом случае все данные информационной базы хранятся в файле с именем 1cv8.1cd. Этот файл имеет двоичный формат и по сути является базой данных для встроенной в «1С:Предприятие 8» СУБД Microsoft SQL Server (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных Microsoft SQL Server.

PostgreSQL (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных PostgreSQL.

IBM DB2 (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных IBM DB2.

Oracle Database (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных Oracle Database.

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

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

Перечислим обязательные таблицы информационной базы.

Config — в этой таблице хранится конфигурация базы данных. Конфигурация базы данных соответствует реальной структуре данных и используется системой «1С:Предприятие» в режиме работы 1С: Предприятие.

ConfigSave — в этой таблице хранится основная конфигурация. Основная конфигурация предназначена для непосредственного редактирования в режиме Конфигуратор.

Files — эта таблица содержит служебную информацию, например, о работе с хранилищем конфигурации.

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

_YearOffset — эта таблица создается только в клиент-серверном варианте работы системы и содержит смещение дат в базе данных.

DBSchema — эта таблица содержит информацию о структуре базы данных «1С:Предприятия» и определяет другие объекты базы данных, используемые данной информационной базой.

V8users — эта таблица содержит список пользователей информационной базы.

_UsersWorkHistory — в этой таблице хранится история работы пользователей.

_SystemSettings — эта таблица содержит хранилище системных настроек.

_RepSettings — эта таблица содержит хранилище настроек отчетов.

_RepVarSettings — эта таблица содержит хранилище настроек вариантов отчетов.

_CommonSettings — эта таблица содержит хранилище общих настроек.

_FrmDtSettings — эта таблица содержит хранилище настроек данных форм.

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

Выполнить проверку информационной базы можно в режиме «Конфигуратор» командой «Администрирование Тестирование и исправление».

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

В файловом варианте работы достаточно скопировать файл 1CV8.1CD в отдельный каталог. Это можно выполнить как ручным копированием, так и с использованием программного обеспечения для резервного копирования и восстановления данных. При этом нужно учесть, что на время копирования работа пользователей с информационной базой должна быть запрещена. Это необходимо для обеспечения целостности и согласованности данных во время создания резервной копии.

В клиент-серверном варианте работы следует создавать резервные копии информационной базы средствами СУБД, под управлением которых работает информационная база «1С:Предприятия». Эти СУБД позволяют выполнять резервное копирование данных в то время, когда база данных находится в многопользовательском режиме и доступна для всех пользователей.

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

Также существенно уменьшается время нахождения информационной базы в однопользовательском режиме в случае файлового варианта работы «1С:Предприятия», а в случае клиент-серверного варианта однопользовательский режим вообще не используется. Кроме этого, положительным моментом является то, что при использовании перечисленных способов можно применять различные специализированные программные средства для создания резервных копий.

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

После префикса следует номер (далее обозначается), который позволяет различать таблицы объектов одинакового вида. Например, если в конфигурации определены два регистра накопления, то в информационной базе могут содержаться таблицы с именами _AccumRg4012 и _AccumRg4018.

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

3.3 Методика развертывания приложения

Техника подключения внешних форм регламентированных отчетов одинакова для всех типовых конфигурации программ на платформе «1С Предприятие 8.2». Для определенности покажем, как подключить внешний отчет в программе «1С Предприятие 8.2».

В стандартной ситуации в программе «1С Предприятие 8.2» формы регламентированной отчетности уже включены непосредственно в информационную базу. Поэтому пользователю, как правило, достаточно следить за выходом новых обновлений и вовремя обновлять свою конфигурацию. Специально подключать отчеты, как это было в «1С Предприятие 7.7», не надо.

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

Для того чтобы можно было использовать внешнюю обработку необходимо открыть 1С, выбрать пункт меню Сервис/Дополнительные отчеты и обработки/Дополнительные внешние обработки (отчеты), рисунок 22.

Рисунок 22 — Добавление внешней обработки (отчета)

После описанных действий откроется окно следующего вида, рисунок 23.

Рисунок 23 — Дополнительные внешние обработки

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

Рисунок 24 — Регистрация внешней обработки

Далее необходимо воспользоваться кнопкой «заменить файл внешней обработки отчета, откроется типовое диалоговое окно для выбора файла (рисунок 25).

Рисунок 25 — Добавление файла внешней обработки

При выборе файла все необходимые поля будут заполнены автоматически, рисунок 26.

Рисунок 26 — Выбор файла внешней обработки (отчета) Для завершения подключения Дополнительной внешней обработки (отчета) достаточно нажать кнопку «Записать» или «ОК».

Стоит отметить, что запуск Дополнительных внешних обработок (отчетов) осуществляется двойным щелчком по выбранной обработке (отчету).

4. УПРАВЛЕНИЕ ИНФОРМАЦИОННЫМ ПРОЕКТОМ

4.1 Выбор жизненного цикла разработки ПО

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

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

Модель жизненного цикла разработки ПО является единственным видом процесса, в котором представлен порядок его осуществления. Модель жизненного цикла разработки ПО (Software Life Cycle Model, SLCM) схематически объясняет, каким образом будут выполняться действия по разработке программного продукта, посредством описания «последовательности» этих действий. Такая последовательность может быть или не быть линейной, поскольку фазы могут следовать друг за другом, повторяться или происходить одновременно. На рисунке 27 представлена простая обобщенная схема процесса.

Рисунок 27 — Обобщенная схема процесса

Модель SLCM — это схема (или основа), используемая разработчиком ПО для определения повторяющегося процесса при создании программного продукта. Она определяет точные инструкции, которые разработчик может использовать для создания только высококачественных программных систем. Понятие жизненного цикла ПО относится ко всем программным проектам, причем независимо от их размеров.

Жизненный цикл — это своего рода «карта-путеводитель» для всех участников проекта, которая помогает им понять, не выходят ли они за определенные для них границы. Для управления программным проектом возникает необходимость в некотором роде карты для планирования действий и хронологий их выполнения.

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

Улучшение и обеспечение качества:

— с помощью стандартизированной процедуры можно наилучшим образом гарантировать завершенность результатов, которые необходимо предоставить;

— определение промежуточных результатов обеспечивает возможность ускорить выполнение оценочных процедур;

— контекст однородных продуктов облегчает их восприятие, я также работу с процедурами оценки.

Возможность проверки затрат на выполнение полного жизненного цикла:

— упрощает процесс создания стандартов разработки для определенного проекта и его оценка;

— стандартизированные процедуры повышают степень «прозрачности» операций по определению затрат и позволяют более эффективно распознавать возможные риски, связанные с затратами;

— одинаковые стандарты уменьшают риск возникновения разногласий между клиентом и разработчиком, а также между главным разработчиком и субподрядчиком;

— в случае применения стандартизированной процедуры становятся «прозрачными» универсальные подходы к методам решения, а следовательно, их можно использовать повторно;

— нежелательный ход процесса разработки возможно выявить на ранней стадии;

— уменьшаются затраты на подготовку персонала.

Улучшается обмен информацией между различными сторонами, участвующими в процессе разработки; происходит снижение зависимости клиента от подрядчика:

— использование определенных терминов уменьшает разногласия, возникающие между всеми задействованными в проекте сторонами;

— пользователь, покупатель и разработчик получают поддержку при формулировании своих требований, а также при описании своих ролей или полученных результатов;

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

«Каркасом» процесса разработки ПО служит модель зрелости функциональных возможностей (Capability Maturity Model, CMM). Она основана на практических действиях, отображает лучшие результаты и определяет потребности индивидов, работающих над усовершенствованием процесса разработки ПО и выполняющих оценочный анализ этого процесса. Модель СММ представляет собой схему, по которой этапы разработки соответствуют пяти уровням развития функциональных возможностей, на основе которых осуществляется непрерывное усовершенствование процесса разработки.

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

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

Определенный. Во всех проектах используется испытанная, адаптированная версия стандартного процесса разработки ПО данной организации.

Управляемый. Собираются детальные показатели процесса разработки ПО и качественные характеристики продукта. Управление процессом разработки программных продуктов осуществляется на количественном уровне.

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

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

Цель определения организационной структуры процесса заключается в разработке и сопровождении стандартного процесса разработки ПО для данной организации.

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

Наиболее известными и широко используемыми жизненными циклами разработки ПО можно назвать следующие: каскад, V — образное эволюционное ускоренное прототипирование, быстрая разработка приложений, инкрементная и спиральная модели.

Для разработки внешней обработки для «1С Предприятие 8.2» мною была выбрана модель разработки рекомендованная компанией 1С, которая базируется на каскадной модели жизненного цикла разработки. Классическая каскадная модель, несмотря на полученную в последнее время негативную оценку, исправно служила специалистам по программному инжинирингу многие годы. Понимание ее сильных сторон и недостатков улучшает оценочный анализ других, зачастую более эффективных моделей жизненного цикла, основанных на данной модели.

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

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

Рисунок 28 — Модель процесса «делать, пока, не будет сделано»

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

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

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

4.2 Определение цели и области действий программного проекта

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

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

— выполнить сбор, спецификацию и аттестацию требований;

— выполнить проектирование информационного и программного обеспечения системы;

— разработать запросы к базам данных и программные коды обработки;

— провести тестирование программного продукта.

Программный проект должен быть:

— продуктом для внутреннего использования в «1С Предприятие 8.2»;

— проектом для осуществления многопользовательского доступа;

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

Программный проект не должен быть:

— проектом, доступным для посторонних лиц.

При определении области действия программного продукта эффективнее всего воспользоваться методикой «будет, не будет». Ниже определены рамки проекта.

Проект будет:

— сетевым;

— использоваться для приема, передачи и обработки данных;