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

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

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

2. ПРОЕКТНАЯ ЧАСТЬ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

o   анализ;

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

o   реализация;

o   внедрение;

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

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

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

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

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

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

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.2 Характеристика архитектуры разрабатываемого проекта

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

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

Пользователями являются также менеджеры филиалов, которые получают готовые файлы с планами по направлениям деятельности, а также финансовые аналитики. Финансовые аналитики получают статистические отчеты. Таким образом, ИС планирования встроена в корпоративную ИС через локальную вычислительную сеть (далее ЛВС) и через взаимодействие серверов БД. На рисунке Рис. 17 представлена техническая архитектура проекта.

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

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

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

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

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

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

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

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10