Автоматизация работы отдела планирования ООО "Кока-Кола ЭйчБиСи Евразия"

финансовые операции;

материально-техническое снабжение;

складское хозяйство;

техническое и сервисное обслуживание.

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

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

Таким образом, SAP Supply Chain Management, не подходит из-за наличия, с одной стороны, излишних функций в программе, а с другой стороны, из-за отсутствия такой важной функции, как планирование доставки (отгрузки) и производства.

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

Покупка функционального модуля информационной системы планирования является экономически выгодной, но полностью противоречит, действующей на предприятии, политике информационной безопасности [17], согласно которой, централизованная автоматизация процессов возможна только для всей системы The Coca-Cola Corporation по всему миру. А если принимается решение автоматизировать локальный процесс внутри одной страны (что позволяется политикой информационной безопасности, действующей на предприятии), то, это возможно осуществить только посредством самостоятельно разработки.

1.3.2 Выбор и обоснование стратегии автоматизации задачи

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

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

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

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

1.3.3 Выбор и обоснование способа приобретения ИС для автоматизации комплекса задач

С позиции информационного менеджмента, создание и внедрение автоматизированной информационной системы планирования может быть выполнено различными способами:

покупка готовой системы;

создание проектной команды и разработка системы средствами и трудовыми ресурсами компании;

заказ системы у компании разработчика [7].

Необходимо рассмотреть различные варианты способов приобретения.

При покупке готовой системы можно приобрести довольно дешевую ИС, но невозможно подобрать программный продукт, который будет на 100% удовлетворять требования компании. Перестройка функционала ИС стоит недешево, поэтому такой вариант не рассматривается.

Если заказывать систему у компании разработчика, то технология работы компании станет известной компании разработчика, а это полностью противоречит политике информационной безопасности компании ООО «Кока-Кола ЭйчБиСи Евразия» [17].

Самостоятельная разработка ИС полностью соответствует политике информационной безопасности компании ООО «Кока-Кола ЭйчБиСи Евразия», а также позволяет гибко изменять запрограммированный механизм ИС, т.е. адаптировать её под новые технические и программные платформы.

1.4 Развёрнутая постановка целей, задачи и подзадач автоматизации

1.4.1 Трансформация базовой технологии решения задачи

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

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



Рис. 10. Ключевой функциональный блок планирования в варианте «КАК ДОЛЖНО БЫТЬ»

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

Необходимо рассмотреть изменения в технологии «КАК ДОЛЖНО БЫТЬ» по сравнению с технологией «КАК ЕСТЬ». К функциональным блокам планирования добавляется функциональный блок формирования статистических отчетов.

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

Рис. 11. Декомпозиция ключевого функционального блока в трансформируемой технологии

Результатами статистических отчетов являются дополнительными аналитическими показателями для АФХД.

Добавляется механизм управления в виде справочников. К ним относятся справочники: «Виды продукции», «Филиалы», «Склады», «Контракты». Данные справочники позволяют структурировать информацию в таблицах БД и формировать результативную информацию. Добавляется механизм исполнения. Это ИС отдела планирования. ИС отдела планирования автоматизирует наиболее рутинные функции планирования. Необходимо рассмотреть технологию формирования планов в варианте «КАК ДОЛЖНО БЫТЬ». В автоматизированном режиме по данным таблиц БД формируются планы-отчеты в табличной форме. Файлы со сформированными статистическими отчетами и планами автоматически загружаются в корпоративную ИС.

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

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

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

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

1.4.2 Цели и назначение автоматизированного варианта решения задачи

Цель автоматизированного варианта решения задачи - достижение прямого и косвенного экономических эффектов.

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

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

1.4.3 Подзадачи автоматизации и функциональная ИТ их решения

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

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

Подзадачи автоматизации - это:

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

формирование плана производства;

формирование плана складирования;

формирование плана доставки;

формирование статистического отчета по видам продукции;

формирование статистического отчета по филиалам;

формирование статистического отчета по складам;

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

Результативная информация - это таблицы, отчеты и файлы: «Отчет по филиалам», «Отчет по видам продукции», «Отчет по складам». Данные отчеты являются статистическими. К результативной информации также относятся отчеты: «План-отчет по продажам», «План-отчет по производству», «План-отчет по складированию», «План-отчет по доставке». Эта информация отображается в виде таблиц и файлов.

Таблицы, с условно-постоянной информацией - это справочники «Склады», «Филиалы», «Виды продукции», «Контракты».

Режим решения задачи - диалоговый.

Периодичность получения результативной информации: статистический отчет по видам продукции, статистический отчет по филиалам, статистический отчет по складам, план продаж и план производства - еженедельно, а план складирования и план доставки - ежедневно.

1.5 Обоснование проектных решений

1.5.1 Обоснование проектных решений по техническому обеспечению

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

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

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

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

Наиболее подходящими характеристиками обладает четырехпроцессорный сервер Flagman QD420. Сервер STSS Flagman QD420 построен на базе четырех высокопроизводительных процессоров AMD® Opteron® с использованием технологии Dual/Quad Core. Данный сервер обладает высокой вычислительной мощностью. Flagman QD420 может применяться как сервер тяжелых баз данных, каковой является БД ИС планирования на предприятии ООО «Кока-Кола ЭйчБиСи Евразия». Обладая высокими вычислительными возможностями, может использоваться в качестве сервера SQL с числом пользователей свыше тысячи.

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

В сервере применяется дисковая подсистема SAS для обеспечения максимальной надежности и производительности на приложениях типа СУБД. Сервер имеет шесть дисковых отсеков для установки жестких дисков с горячей заменой.

Основные характеристики сервера Flagman QD420:

четыре двух-/четырех- ядерных процессора AMD® Opteron® 8000-series Dual/Quad Core AMD64;

до 128Gb оперативной памяти DDR-2 PC2-5300 ECC Registered;

дисковая подсистема SAS/SATA onBoard RAID 0,1,10 (SAS RAID-5,6 - опционально);

два интегрированных сетевых адаптера 10/100/1000Mbit Ethernet;

система управления сервером IPMI 2.0 Server Management (опционально);

корпус 2U Rackmount.

Других технических элементов для технического обеспечения задачи автоматизации не требуется. Клиентская часть программы устанавливается на компьютерах РС сотрудников отдела планирования. Они обладают всеми необходимыми техническими характеристиками. Характеристика РС отдела планирования: рабочая станция STSS Flagman WP110 построена на базе новейшего процессора компании Intel® с использованием технологии Dual/Quad Core™; процессор Intel® Core™ 2 является на данный момент самым высокопроизводительным в линейке процессоров компании Intel®.

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

Данные РС являются офисными ПК с расширенными возможностями

Основные характеристики РС:

двуядерный процессор Intel® Core™ 2 / Pentium® Dual-Core EM64T;

до 8Gb оперативной памяти DDR2 PC2-5300;

дисковая подсистема SATA onBoard RAID;

интегрированный сетевой адаптер 10/100/1000Mbit Ethernet;

видеоадаптер nVidia GeForce 7300/7600/8500/8600/8800;

корпус MidiTower.

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

1.5.2 Обоснование проектных решений по информационному обеспечению

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

К внемашинному информационному обеспечению можно отнести следующие информационные документы:

инструкция пользователя ИС планирования;

инструкция по инсталляции ПО ИС отдела планирования.

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

Инструкция по инсталляции позволяет правильно установить и запустить ПО ИС планирования.

В состав базы данных ИС планирования должны входить следующие таблицы:

таблица «Продажи», поскольку она будет содержать данные для формирования плана продаж;

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

таблица «Сток», поскольку она будет содержать данные для формирования плана по складированию;

таблица «Доставка» », поскольку она будет содержать данные для формирования статистических;

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

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

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

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

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

Также, в состав базы данных ИС входят справочники, которые будут содержать необходимую для формирования планов и статистических отчетов, условно-постоянную, информацию:

справочник «Склады»;

справочник «Филиалы»;

справочник «Виды продукции»;

справочник «Контракты».

Существуют три метода классификации объектов: иерархический, фасетный и дескрипторный. Иерархическая система классификации делит объекты по классификационному признаку на уровни. При этом признаки классификации каждого уровня в последовательности зависят друг от друга. Фасетная система классификации позволяет выбирать признаки классификации независимо друг от друга. Дескрипторная система классификации широко используется в библиотечной системе поиска [3].

Для данной проектируемой системы АИС желательно использовать иерархическую систему классификации, т.к. кодируемые множества не являются сложными и характеризуются одним уровнем классификации.

1.5.3 Обоснование проектных решений по программному обеспечению

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

Для организации клиентских рабочих мест ИС планирования необходима ОС Windows 2000 или ОС Windows ХР. ОС Windows ХР установлена на всех компьютерах предприятия, поэтому установки дополнительной ОС не требуется.

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

MS Project, для разработки календарного плана-графика;

MS Visio, для разработки всех схем ИС;

ERWIN, для разработки схемы данных;

Данные ПС являются вспомогательными и используются при осуществлении проектирования.

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

Ниже приведены характеристики рассматриваемых СУБД, которые можно использовать с ИС отдела планирования.

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

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

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

Clipper - алгоритмический язык программирования традиционной структуры. Набор служебных слов очень велик, поскольку велика номенклатура команд и библиотечных функций. Команды, условно объединяемые под общим названием «команды выполнения операций по реализации алгоритма» можно разделить на три группы: манипуляции с файлами, выполнение вычислений, организация диалогового режима.

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

FoxPro содержит набор утилит для выполнения трудоемких операций, как то создание падающих меню, экранных форм, генерации отчетов, таким образом, приближаясь к визуальным системам программирования, кроме этого, FoxPro имеет встроенный отладчик, функции обработки событий, что позволяет создавать Windows-подобные интерфейсы, предоставляет средства конфигурации самой системы, возможность создания многооконного и многозадачного интерфейса. С точки зрения СУБД, предоставляют средства доступа и обработки мемо-полей, технология Rushmore (локализация записей с общим признаком), многоиндексные файлы, средства язык SQL для создания запросов, специализированные команды обработки массивов, управление цветами. Также, автоматизированы самые популярные циклы создания интерфейса - цикл регенерации меню после выбора команды и цикл регенерации окна редактирования записи базы данных. За счет этих возможностей в СУБД FoxPro может быть реализован удобный, гибкий и эффектный пользовательский интерфейс. При всех достоинствах FoxPro имеет высокую стоимость лицензии.

Работа с реляционными таблицами, хранящимися в файлах БД, является одним из самых сильных мест системы Clarion.. Вполне возможно, что построенная информационная модель далека от оптимальной, обладает неприятными коллизиями или даже является противоречивой. Средства предоставляет Clarion для статического анализа информационной модели. Clarion позволяет обеспечить достаточно полноценную работу в архитектуре клиент/сервер, вне зависимости от того, какая модель доступа к удаленным данным используется. При инсталляции и функционировании Clarion не имеет высоких аппаратных требований. Clarion позволяется обеспечить создание как фундаментального, так и вариативного компонентного программирования. Clarion эффективно используется для создания информационных систем, как для отдельных бизнес-процессов, так и для предприятия в целом. Шаблоны СУБД Clarion позволяют быстро и эффективно генерировать экранные формы, на основе которых формируются объектные программные модули. Clarion по своим функциональным возможностям не уступает выше перечисленным СУБД, но при этом лицензионная версия не является дорогой.

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

2. Проектная часть

2.1 Разработка проекта автоматизации: информационный менеджмент

2.1.1 Этапы жизненного цикла проекта автоматизации

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

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

Таким образом, жизненный цикл информационной системы охватывает все стадии и этапы ее создания, сопровождения и развития:

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

проектирование системы (включая разработку технического задания, эскизного и технического проектов);

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

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

эксплуатацию системы и ее сопровождение;

развитие системы [10].

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

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

В России, создание и испытания автоматизированных систем, к которым относятся и информационные системы, регламентированы рядом ГОСТов, прежде всего серии 34. Однако, отдельные положения этих ГОСТов уже устарели, а ряд этапов жизненного цикла информационных систем предоставлены недостаточно полно. Международный стандарт ISO/IEC 12207 определяет структуру жизненного цикла, содержащую процессы, которые должны быть выполнены во время создания программного обеспечения информационной системы.

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

Однако стандарт ISO/IEC 12207 не предлагает конкретной модели жизненного цикла и методов разработки, его рекомендации являются общими для любых моделей жизненного цикла. Он ориентирован на разработку ИС в рамках предприятия. Другие стандарты более ориентированы на производителей ИС и подразумевают более жесткие требования.

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



Рис.12. Каскадная модель жизненного цикла

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

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

Рис. 13. Модель жизненного цикла с промежуточным контролем

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

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

Рис. 14. Спиральная модель

автоматизация стратегия информационный программный экономический

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

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

Она имеет следующие этапы:

анализ;

проектирование;

реализация;

внедрение;

сопровождение;

Цель этапа «Анализ» - формирование технического задания. Этап разбивается на подэтапы, задачи которых: определений требований к ИС, определение функций ИС и стратегий автоматизации, обоснование проектных решений по техническому, информационному и программному обеспечению. Результативная информация - это документация по техническому заданию. Информация для анализа берется из интернета и отдела планирования.

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

Цель этапа «Реализация» - разработка программного обеспечения ИС. Этап включает в себя подготовку к разработке ПО и разработку ПО. Результативная информация - это документация по ПО.

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

Цель этапа «Сопровождение» - мониторинг и доработка программного и технического обеспечения ИС в процессе эксплуатации, а также работа с пользователями.

2.1.2 Разработка и описание проекта автоматизации, плана-графика автоматизации и сетевой модели задачи

При формировании плана-графика использовалось программное приложение MS Project 2003 [13].

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

Рис. 15. Диаграмма Ганта без этапа «Внедрение»

Длительность проекта 71 день. Начало проекта 3 сентября 2007 года, окончание проекта 10 декабря 2007 года.

Первый этап «Анализ». Этот этап начинается с подэтапа «Определение требований к ИС». Начало подэтапа 3 сентября 2007, окончание подэтапа 6 сентября 2007, длительность подэтапа 4 дня. Первая задача - «Анализ бизнес-процессов КАК ЕСТЬ». Выполняет данную задачу менеджер по проектированию ИС и менеджер отдела планирования. При выполнении задачи строится структурно - функциональная диаграмма бизнес-процессов КАК ЕСТЬ в нотации IDEF0. На анализ бизнес-процессов отводится 2 дня. На основании проведенного анализа выбирается комплекс задач автоматизации. Данную задачу осуществляет менеджер по проектированию ИС. На эту задачу отводится 1 день. Эти две задачи осуществляются параллельно. Следующая задача подэтапа «Выбор задачи проектирования в комплексе задач», осуществляет данную задачу менеджер по проектированию ИС и менеджер ИТ отдела. На данную задачу также отводится 1 день. Последняя задача подэтапа это «Определение свойств ИС, требуемых для решения задачи». Участники - менеджер по проектированию ИС и менеджер ИТ отдела. Длительность - 1 день.

Следующий подэтап в этапе «Анализ» - определение функций будущей ИС и стратегии автоматизации. Участниками являются менеджеры по планированию, по проектированию ИС и ИТ отдела. Подэтап начинается 7 сентября 2007, заканчивается 12 сентября 2007. Длительность этапа 4 дня.

Первая задача подэтапа - «Анализ существующих разработок» в данной предметной области. Задача выполняется в один день. Следующая задача подэтапа - «Выбор способа приобретения ИС». На задачу также отводится 1 день. Далее следует задача - «Выбор стратегии автоматизации», в рамках которой определяется не только стратегия автоматизации, но и объем системы (АИС или АРМ). На эту задачу отводится 1 день. Эти две задачи также определяются параллельно. Последняя задача подэтапа - «Определение целей и задач автоматизации». На последнюю задачу отводится 2 дня, т.к. она является ключевой в формировании технического задания.

Предпоследний подэтап этапа «Анализ» это «Обоснование проектных решений». Начало подэтапа 13 сентября 2007, окончание 21 сентября 2007. Длительность подэтапа 6 дней. Подэтап состоит из трех основных задач: обоснование проектных решений по информационному обеспечению, обоснование проектных решений по техническому обеспечению, обоснование проектных решений по программному обеспечению. Цель данных задач - сформировать необходимые требования к вышеперечисленным видам обеспечения ИС. Участниками данного подэтапа являются менеджеры по проектированию ИС и ИТ отдела.

Последний подэтап этапа «Анализ» - это создание документации по техническому заданию. Длительность данного подэтапа 1 день.

Следующий этап «Проектирование». Начало этапа 24 сентября 2007, окончание 3 октября 2007. Длительность подэтапа 8 дней. Этап состоит из двух подэтапов. Первый подэтап это «Разработка проекта автоматизации». Длительность подэтапа 4 дня. Первая задача подэтапа это «Разработка плана-графика автоматизации». Разработку проводит менеджер по проектированию ИС. Задача выполняется в течение одного дня. Следующая задача - «Оценка стоимости проекта». Эту задачу решает экономист, на основании разработанного плана-графика. Следующая задача - «Разработка архитектуры проекта». В рамках данной задачи разрабатываются техническая и программная архитектуры проекта, а также архитектура пользователей. На данную задачу отводится 1 день. Эта задача решается параллельно с оценкой стоимости проекта. Следующая задача «Анализ рисков проекта». Задача осуществляется в течение одного дня. Вышеперечисленные задачи подэтапа выполняют менеджеры по проектированию ИС и ИТ отдела.

Следующий подэтап этапа - «Разработка информационного обеспечения задачи». Длительность подэтапа 3 дня. Начало этапа 28 сентября октября 2007, окончание 2 октября 2007. Участниками являются программист 1 и менеджер по проектированию ИС. Первая задача - это «Разработка информационной модели» будущей ИС. Задача осуществляется в течении одного дня менеджером по проектированию ИС. Следующая задача подэтапа - «Разработка классификаторов для ИС». Задача осуществляется в течение одного дня программистом 1 и менеджером по проектированию ИС. Последняя задача подэтапа - это «Разработка прототипов экранных форм». Прототипы экранных форм согласовываются с будущими пользователями. Задача осуществляется в течение одного дня менеджером по проектированию ИС и программистом 1. Последним подэтапом является создание проектной документации на основании проведенных разработок. Срок исполнения 1 день, выполняется менеджером по проектированию ИС.

Следующий этап это «Реализация». Начало этапа 4 октября 2007, окончание 21 ноября 2007. Длительность этапа 35 дней. Этап реализации начинается с подготовки к разработке ПО. Первый подэтап состоит из трех задач. Первая задача это «Покупка и установка программных средств» для осуществления разработки. В этом варианте ИС к программным средствам относится СУБД CLARION, т.к. разработка программного обеспечения производится на основе СУБД CLARION. ОС остается прежней. Задачу осуществляет менеджер по проектированию ИС и менеджер ИТ отдела. Длительность задачи 2 дня. Вторая задача это «Формализация расчетов результативных показателей». Задача осуществляется в течение одного дня программистом 2.

Последняя задача подэтапа - «Разработка алгоритмов» программных модулей. Задача осуществляется в течение трех дней программистом 2. Последний подэтап это «Разработка программного обеспечения». Длительность подэтапа 28 дней. Исполнители подэтапа - программист 1 и программист 2. Разработка ПО начинается с разработки БД на основе ранее разработанной информационной модели. Задача осуществляется в течение семи дней. Вторая зада - это «Разработка интерфейса». Длительность 5 дней. Интерфейс разрабатывает программист 1.

Следующая задача «Разработка программных модулей ИС». Выполнение данной задачи является самым длительным, 14 дней. После разработки программных модулей разрабатывается взаимодействие программных модулей или схема программного пакета. Данная задача осуществляется в течение 5 дней. Последняя задача после разработки программы это «Разработка тестов для проверки ПО». Этап «Реализация» завершается разработкой тестов для проверки ПО. Участниками являются менеджер по проектированию ИС, программист 1 и программист 2.

2.1.3 Характеристика архитектуры разрабатываемого проекта

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



Рис. 16. Организационная архитектура проекта

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

Таким образом, ИС планирования встроена в корпоративную ИС через локальную вычислительную сеть (далее ЛВС) и через взаимодействие серверов БД.

На рисунке Рис. 17 представлена техническая архитектура проекта.



Рис. 17. Техническая архитектура проекта

Техническая архитектура ИС отдела планирования встраивается в техническую архитектуру корпоративной ИС с учетом наличия уже существующих технических элементов. В технической архитектуре пользователей ИС добавляется сервер БД ИС планирования. БД ИС планирования взаимодействует с сервером корпоративной ИС. Подключение к интернету остается тем же. На сервере БД ИС планирования размещена серверная часть ПО, а клиентская - на компьютерах пользователей отдела планирования, которые непосредственно работают с ИС. То есть, используется наиболее распространенная архитектура толстый «клиент-сервер». Через VPN-сервер осуществляется выход в интернет. Сервер печати обеспечивает распределенный вывод на печать с РС в отделе планирования. Через сервер Remote administrator производится ограничение и распределение доступа пользователей. Так, например, с сервера БД менеджеры филиалов могут получать информацию по планам только в соответствии со своим направлением деятельности. Другие пользователи корпоративной ИС не имеют доступа к информации по планам.

На рисунке Рис. 18 представлена программная архитектура проекта.

Рис. 18. Программная архитектура проекта

В программной архитектуре проекта остается то же программное обеспечение, что и в программной архитектуре всего предприятия, но только то, которым пользуется отдел планирования. Добавляется серверная часть ПО отдела планирования, размещаемая на сервере БД и клиентская программа ИС отдела планирования, размещенная на РС отдела планирования. Сервера БД (корпоративный и ИС отдела планирования) взаимодействуют по протоколу прикладного уровня SNMP 1.1.

2.1.4 Характеристика этапа внедрения разрабатываемого проекта

На рисунке 2.7 представлен план-график этапа внедрения.

Этап внедрения состоит из двух подэтапов: создание среды функционирования ИС и тестирования ИС. Дата начала этапа 22 ноября 2007, окончание 17 декабря 2007.

Рисунок 2.7. План-график этапа внедрения

Длительность этапа внедрения 18 дней. Подэтап «Создание среды функционирования ИС» осуществляется в течение 5 дней. Первая задача подэтапа это «Покупка элементов технической архитектуры» проекта.

В проекте приобретается сервер БД ИС планирования. Осуществляется менеджером по проектированию ИС и системным администратором. Вторая задача это «Установка сервера БД». Установку производят менеджер по проектированию ИС и системный администратор. На данную задачу отводится 2 дня.

Последняя задача подэтапа - «Установка ПО ИС» на ПК сотрудников отдела планирования и сервер БД ИС планирования. Данная задача осуществляется в течение одного дня системным администратором.

Следующий подэтап - это «Тестирование ИС», подэтап начинается 29 ноября 2007, заканчивается 10 декабря 2007. Длительность этапа 8 дней. Осуществляется системным администратором, программистом 1 и программистом 2.

Первая задача - «Тестирование технического обеспечения ИС». Это проверка технического обеспечения ИС, как вновь установленного, так и имеющегося.

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

Следующая задача подэтапа это «Тестирование программных модулей». Задача осуществляется программистами 1 и 2 в течение трех дней на основе тестов, разработанных для проверки ПС.

Предпоследняя задача - устранение ошибок, выявленных при тестировании. Задачу осуществляют программисты 1 и 2 и системный администратор. Срок выполнения задачи - 2 дня.

Последняя зада - это «Обучение пользователей». Задача осуществляется менеджером по проектированию ИС в течение пяти дней.

2.1.5 Характеристика этапа эксплуатации разрабатываемого проекта и возможных работ

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

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

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

2.1.6 Ожидаемые риски на этапах жизненного цикла и их описание

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

На подэтапе «Определение функций ИС и стратегий автоматизации» основной риск это неправильное определение функций ИС и стратегии автоматизации. На данном подэтапе существует риск неправильного выбора способа приобретения ИС. Риск предотвращается основательным анализом всех вариантов. В случае возникновения, риск устраняется проведением повторного анализа вариантов выбора ИС. Риск взаимосвязан с риском неправильного определения функций ИС и стратегии автоматизации. Данный риск предотвращается и устраняется использование современных case-средств в процессе анализа.

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

На подэтапе «Разработка информационного обеспечения задачи» основные риски - это разработка неправильной информационной модели и неудобных для пользователя прототипов экранных форм. Риск предотвращается по согласованию прототипов экранных форм с будущими пользователями, а устраняется дополнительной доработкой экранных форм, а также использованием системы Model View Control (MVC).

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

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

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

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

2.1.7 Оценка стоимостных параметров проекта автоматизации

При оценке стоимостных параметров использовалось программное приложение MS Project 2003 [13].

На рисунке представлена таблица ресурсов проекта.

Используемые трудовые ресурсы (участники) на этапах жизненного цикла проекта указаны в пункте 2.1.2. На этапах проектирования также используются трудовые ресурсы: компьютер, интернет, сервер БД, сетевое оборудование, электричество по ПК и электричество по серверу; т.е. под трудовыми ресурсами в данном случае подразумевается часовая амортизация используемые средств.

Также, закупаются следующие материальные ресурсы: MS Project, MS Visio, ERWIN, CLARION, сервер БД и канцтовары.

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

Рис. 19. Таблица ресурсов проекта

MS Project используется при разработке плана-графика автоматизации, оценке стоимости проекта, создании проектной документации. MS Visio используется при создании документации по техническому заданию, при разработке информационной модели, разработке классификаторов, разработке алгоритмов, создании документации по ПО. ERWIN используется в задачах подэтапа определения требований к ИС, а также при создании документации по техническому заданию и создании проектной документации. CLARION используется при разработке программного обеспечения, тестирования ИС, доработке программного обеспечения ИС, а также при создании проектной документации, создании документации по ПО и корректировке данных видов документаций на этапе сопровождения.