Разработка модуля внешней обработки для "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.SYSTEM REQUIREMENTS life cycle model, the methodology for design, modeling, design, implementation, 1C, DATABASE TESTING PHYSICAL PRESENTATION SYSTEM LOGICAL VIEW SYSTEMS, ACS data analysis.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")."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.project implemented a software module "Sales by product matrices", accelerating the process of analyzing sales of goods.results can be applied to the Company " Krepejnaya Kompaniya " to increase turnover and profit increase.

ВВЕДЕНИЕ

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

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

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

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

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С для создания отчета не подходят.

.4 Сбор требований

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

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

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

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

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

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

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

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

ВопросОтветЧто требуется от отчета? Выведение данных о продажах товараКакие дополнительные параметры отбора должны присутствовать? Возможность выбрать интервал времени, который нас интересует и товарКаким должно быть оформление?Все должно быть наиболее простым и понятным

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.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 - Рабочий интерфейс

.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.DB2 (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных IBM DB2.Database (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных Oracle Database.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. УПРАВЛЕНИЕ ИНФОРМАЦИОННЫМ ПРОЕКТОМ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-сетевым;

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

-предназначен для анализа и выведения данных по запросу;

-применяться в операционных системах Windows.

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

-использоваться в системах отличных от Windows.

.3 Создание структуры пооперационного перечня работ

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

-этап исследование концепции;

-этап определения структуры проекта;

-этап определения требований;

-этап разработки проекта;

-этап внедрения проекта;

-этап установки.

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

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

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

Рисунок 29 - Пооперационный перечень работ ИС

.4 Идентификация задач и действий

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

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

-исследование концепции, то есть определение структуры системы, определение требований;

-определение структуры проекта, который включает в себя анализ функций и декомпозицию требований;

-определение требований (определение и разработка требований к ПО, расстановка приоритетов и интеграция требований);

-разработка проекта, включает в себя проектирование запросов, отладку и проектирование интерфейса;

-внедрение проекта (планирование интеграции, выполнение интеграции, планирование тестирования, выполнение тестирования);

-установка.

.5 Оценка размера и возможности повторного использования

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

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

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

Повторное использование может обеспечить прогресс на следующих направлениях:

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

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

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

-совместимость. Должна присутствовать гибкость программного продукта с другими системами, что существенно повысить его качество, то есть программный продукт должен легко совмещаться с другими;

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

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

Модули отчета, ввиду создания их в системе компоновки данных, повторно использоваться не могут.

.6 Оценка длительности и стоимости разработки проекта

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

Диаграмма Ганта - это один из наиболее популярных способов графического представления плана проекта, применяемый во многих программах управления проектами.

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

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

Одним из наиболее важных свойств любого ресурса является стоимость (Cost (Затраты)) его использования в проекте. В MS Project выделяется два типа стоимости ресурсов: повременная ставка и стоимость за использование. Повременная ставка (Rate) выражается в стоимости использования ресурса в единицу времени, например 50 рублей в час или 400 рублей в день. Повременная ставка используется для людских, а также для каких-либо материальных ресурсов. В таком случае стоимость участия ресурса в проекте составит время, в течение которого он работает в проекте, умноженное на почасовую ставку. В разработанном мной проекте использовалась повременная ставка (рисунок 30). Общие же затраты на использование ресурсов по всему проекту можно увидеть на рисунке 31.

Рисунок 30 - Повременная ставка в использовании ресурса

Рисунок 31 - Общие затраты на использовании ресурсов проекта в третьем проходе

.7 Распределение ресурсов проекта

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

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

Распределение ресурсов проекта при создании модуля «продажи по товарным матрицам» можно представить в виде перечня представленного на рисунке 32.

Рисунок 32 - Распределение ресурсов проекта

.8 Оценка экономической эффективности проекта

В целом, разрабатываемая ИС и ее отдельные программные модули, направлены на получение или увеличения прибыли. Заказчиком данного продукта является ООО «Крепежная Компания». ООО «Крепежная Компания» - сеть магазинов оптово-розничной торговки строительными и крепежными материалами. В этом случае, эффективность внедрения системы будет оцениваться с позиции быстроты, удобства и качества выполнения расчетов.

Для оценки эффективности воспользуемся методом экспертных оценок. Метод расчета в данном случае состоит из нескольких этапов:

?выделить цели работы системы;

?определить наборы показателей, характеризующих определенную цель;

?определить уровень достижения показателя;

?рассчитать степень достижения каждой цели по выдвинутым показателям;

?определить весовые коэффициенты целей;

?рассчитать общий показатель эффективности разрабатываемой информационной системы.

Для оценки эффективности воспользуемся методом экспертных оценок. Метод расчета в данном случае состоит из нескольких этапов:

?выделить цели работы системы;

?определить наборы показателей, характеризующих определенную цель;

?определить уровень достижения показателя;

?рассчитать степень достижения каждой цели по выдвинутым показателям;

?определить весовые коэффициенты целей;

?рассчитать общий показатель эффективности разрабатываемой информационной системы.

Степень достижения цели рассчитывается как средняя величина достижения частных показателей. Формула расчета имеет следующий вид:

,(4.1)

гдеu(gi) - степень достижения цели, баллы;

- значение показателя, баллы;- количество показателей.

Весовой коэффициент вычисляется по формуле:

,(4.2)

где - весовой коэффициент, баллы;i - оценка, баллы.

Расчет оценки ведется по формуле:

, (4.3)

где Vi - оценка, баллы;min - минимальное значение ранга, баллы;i - сумма рангов, баллы.

Для расчета суммы рангов воспользуемся формулой:

,(4.4)

где Ri - сумма рангов, баллы;i - значение, выставленное экспертом, баллы;- количество экспертов.

При этом проверяется согласованность мнений экспертов путем расчета значения известного коэффициента q Кендала (конкордации), для оценок данных экспертами.

Общий показатель эффективности рассчитывается как:

,(4.5)

где Em - показатель эффективности, баллы;i - весовой коэффициент, баллы;(gi) - степень достижения цели, баллы.

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

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

Все это сведем в таблицу (таблица 4.1).

Таблица 4.1 - Цели, показатели и уровень достижения работы ИС

ЦельПоказательУровень достижения, баллы Степень достижения целейg1 - технический уровеньy11 - минимизация количества ошибок при выполнении лабораторных исследований 0,850,916666667y12 - автоматизированный ввод результатов ручных методов исследований0,9y13 - автоматизация получения заказов, выдачи результатов и отчетов1g2 - коммуникацияy21 - оперативность0,820,86y22 - удобство использования0,9g3 - социальные целиy31 - улучшение условий труда0,850,88y32 - внедрение групповых форм работы0,79y33 - уменьшение времени выполнения иссле-дований1g4 - получение отчетностиy41 - автоматическое получение отчетов0,90,95y42 - уменьшение объема рутинной работы персонала лаборатории1g5 - простота использованияy51 - легко понимаемый интерфейс пользователя0,950,883333333y52 - возможность поиска0,8y53 - возможность сохранения, извлечения и редактирования документов0,9

Для определения весовых коэффициентов был применен экспертный опрос десяти человек. Список опрошенных приведен в таблице 4.2.

Таблица 4.2 - Список опрошенных

ФИО опрошенногоДолжностьСавченко Н.ЯДиректорКолесников А.Н.Заместитель директораГерасименко И.А.Старший аналитикСонина Ж.Е.Аналитик розничных продажПетров Е.М.Аналитик оптовых продажЩебетунова М.И.Аналитик закупок

Таблица 4.2 - Список опрошенных продолжение

Курочкин Ф.П.Руководитель отдела продажТумакова И.Н.Руководитель отдела снабженияИвко Д.В.Сотрудник отдела продажМельникова Т.С.Сотрудник отдела снабженияКожник Д.А.Сотрудник отдела продаж

Таблица 4.3 - Результаты опроса в баллах

ЭкспертыКритерии оценкиg1g2g3g4g5Э143412Э234512Э334521Э451423Э532541Э635412Э734521Э853421Э943215Э1034521Ранг R3633431819Ранг минимальный18Оценка0,500,550,421,000,95Общая оценка3,41Весовой коэффициент0,146566210,159890410,142706590,2989320,27770439Общий показатель эффективности0,987133001

Таким образом, можно сказать, что эффективность работы разработанной информационной системы по отношению к заданным целям составляет 99%. Неэффективность работы ИС составляет 1%. На основании представленных результатов можно сделать вывод, что внедрение проекта «Продажи по товарным матрицам для "1С:Предприятие 8.2"» - целесообразно.

В четвертой главе произведено обоснование выбора жизненного цикла информационной системы и выделено, что наиболее оптимальным вариантом технологии проектирования является каскадная модель. Определены цели и область действия ПП, создана структура пооперационного перечня работ (проект создания информационной системы реализован в Microsoft Project. Определены используемые в проекте ресурсы и на последнем этапе проведена оценка эффективности прототипа ИС, которая показала, что внедрение проекта целесообразно.

ЗАКЛЮЧЕНИЕ

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

Первым этапом дипломного проекта являлась определение цели и задач дипломного проекта. Был проведен анализ существующих систем.

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

В первом разделе выполнено бизнес моделирование бизнес-моделирование процессов организации. Построена диаграмма бизнес-вариантов использования представляющая основные направления деятельности организации и построена диаграмма вариантов использования информационной системы.

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

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

После проектирования интерфейса программы, осуществлено моделирование структуры данных (логическая и физическая модели). Программное средство используемое для создания CASE-средства использовался программный продукт Rational Rose 2000 Enterprise Edition. Был рассмотрен использованный программный инструментарий. В качестве среды разработки программного обеспечения была использована встроенная в программный комплекс «1С:Предприятие 8.2» СКД - система компоновки данных.

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

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

В четвертом разделе дипломного проекта определялась цель и область действия программного продукта. Осуществлен выбор модели жизненного цикла процесса разработки по результатам, представленным в таблице 4.1 - «Определение оптимальной модели жизненного цикла в баллах». Составлена структура пооперационного перечня работ с использованием пакета управления проектами Microsoft Project 2010, на её основе построен график выполнения работ, приведена диаграмма Ганта. Была рассчитана экономическая эффективность проекта.

По ходу выполнения дипломного проектирования были использованы такие программные продукты как:

-ERWin 4.0;

-1С: Предприятие 8.2;

-MS Project 2010;

-MS Word 2010;

-MS Excel 2010;

-Rational Rose.

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

Результаты интеллектуальной деятельности

Специальность: «ИТ» (в управлении)

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

Предполагаемый РИД:

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

?расчет продаж по клиентам;

?графическое отображение результатов расчета;

?расчет продаж в заданном временном промежутке;

?создание, сохранение и печать отчетов по результатам расчетов.

Системные требования к программно-аппаратной среде, в которой используется ПО:

?операционная система Microsoft Windows XP, Windows 7;

?программный комплекс «1С: Предприятие 8.2».

Эксплуатация программного модуля позволит на 40% сократить расходы на закупку, хранение и транспортировку товаров.

Предполагаемые пользователи (Заказчики РИД): компания ООО «Крепежная Компания» и другие торговые компании.

СПИСОК СОКРАЩЕНИЙ

БД - база данных;

ГИ - графический интерфейс;

ГИП - графический интерфейс пользователя;

ЖЦ - жизненный цикл;

ИС - информационная система;

ПМ - программный модуль;

ПО - программное обеспечение;

ПП - программный продукт;

ПК - персональный компьютер;

СУБД - система управления базами данных;

COM - component object model;- Online Analytical Processing, система обработки аналитической информации; - software life cycle model, модель жизненного цикла.

СПИСОК ЛИТЕРАТУРЫ

1.Рязанцева Н.А., Рязанцев Д.Н. 1С:Предприятие. Комплексная конфигурация. Секреты работы. - СПб.: БХВ-Питербург, 2004. - 624с.:ил.

.Экономическая информатика / Под ред. П.В. Конюховского и Д.Н. Колесова. - СПб: Питер, 2001. - 560с.: ил.

.Кощеева Е.Л. Создание и использование музейных информационных ресурсов // Музей будущего: информационный менеджмент / Сост. А.В. Лебедев. М.: Прогресс-Традиция, 2009. - С.35-45. #"justify">Техническое задание на разработку внешней обработки для 1С Предприятие 8.2 "Продажи по товарным матрицам"

Оглавление

1. Наименование программы73

.1. Назначение и область применения73

. Требования к программе73

.1. Требования к функциональным характеристикам73

.2. Требования к надежности73

.2.1. Требования к обеспечению надежного функционирования программы73

.2.2. Время восстановления после отказа73

.2.3. Отказы из-за некорректных действий пользователей системы73

. Условия эксплуатации73

.1. Требования к квалификации и численности персонала73

.2. Требования к составу и параметрам технических средств73

.3. Требования к информационной и программной совместимости73

.3.1. Требования к информационным структурам и методам решения73

.3.2. Требования к исходным кодам и языкам программирования73

.3.3. Требования к программным средствам, используемым программой73

.3.4. Требования к защите информации и программ73

.4. Специальные требования73

. Требования к программной документации73

.1. Предварительный состав программной документации73

. Порядок контроля и приемки73

.1. Виды испытаний73

.2. Общие требования к приемке работы73

1. Наименование программы

Наименование программы: "Продажи по товарным матрицам"

1.1. Назначение и область применения

Внешняя обработка предназначена для вывода данных по продажам ООО «СтройКрепеж» и включает следующее:

.1.1. Анализ продаж по товарам1.1.2. Анализ продаж по контрагентам1.1.3. Вывод диаграмм1.1.4. Вывод отчётов

Данный отчет представляет собой внешнюю обработку разработанную для платформы 1С Предприятие 8.2, конфигурации Управление Торговлей 10.3.

2. Требования к программе

·Выведение данных о продажах товара;

·Возможность выбрать интервал времени, который нас интересует и товар;

·Все товары, суммы продаж товаров за выбранный период с разбивкой по месяцам и количество продаж каждого товара, а так же суммарный объем продаж;

·Данные продаж должны группироваться по контрагентам и номенклатуре;

·Возможность формирования диаграмм по результатам анализа.

2.1. Требования к функциональным характеристикам

Программа должна обеспечивать возможность выполнения перечисленных ниже функций:2.1.1. Анализ продаж по товарам;2.1.2. Анализ продаж по контрагентам;2.1.3. Вывод диаграмм;2.1.4. Вывод отчётов.

2.2. Требования к надежности

Данный отчет должен быть доступен 95% рабочего времени.

2.2.1. Требования к обеспечению надежного функционирования программы

Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже: а) организацией бесперебойного питания технических средств; б) использованием лицензионного программного обеспечения; в) регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»; г) регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов

2.2.2. Время восстановления после отказа

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

2.2.3. Отказы из-за некорректных действий пользователей системы

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

3. Условия эксплуатации

Эксплуатация данной эксплуатации осуществляется только с конфигураций Управление Торговлей 10.3.0.13.

3.1. Требования к квалификации и численности персонала

Требования не определены.

3.2. Требования к составу и параметрам технических средств

3.2.1. В состав технических средств должен входить IВМ-совместимый персональный компьютер, включающий в себя:

.2.2. Процессор Pentium-2.0Hz, не менее или аналогичный AMD; 3.2.3. Оперативную память объемом, 1 Гигабайт, не менее; 3.2.4. HDD, 40 Гигабайт, не менее; 3.2.5. Операционную систему Windows XP или новее;

3.3. Требования к информационной и программной совместимости

Требования не определены.

3.3.1. Требования к информационным структурам и методам решения

База данных работает под управлением SQLite. Используется много поточный доступ к базе данных.

3.3.2. Требования к исходным кодам и языкам программирования

Дополнительные требования не предъявляются.

3.3.3. Требования к программным средствам, используемым программой

Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows XP или более поздней версией.

3.3.4. Требования к защите информации и программ

Требования к защите информации и программ не предъявляются.

3.4. Специальные требования

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

4. Требования к программной документации

Требования не определены.

4.1. Предварительный состав программной документации

Состав программной документации должен включать в себя: 4.1.1. Техническое задание;4.1.2. Программу и методики испытаний;4.1.3. Руководство оператора;

5. Порядок контроля и приемки

.1. Виды испытаний

Приемо-сдаточные испытания должны проводиться на объекте Заказчика в оговоренные сроки. Приемо-сдаточные испытания программы должны проводиться согласно разработанной Исполнителем и согласованной Заказчиком Программы и методик испытаний. Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний

5.2. Общие требования к приемке работы

На основании Протокола проведения испытаний Исполнитель совместно с Заказчиком подписывает Акт приемки-сдачи программы в эксплуатацию.

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

Больше работ по теме: