32
Техническое обеспечение - это комплекс технических средств, обеспечивающих ра-
боту ИС, соответствующей документации на эти средства и технологические процессы.
В настоящее время существует несколько технологий передачи данных. Рассмот-
рим две архитектуры, такие как файл-сервер и клиент-сервер.
В архитектуре «клиент-сервер» сервер базы данных не только обеспечивает доступ
к общим данным и обработку этих данных. Клиент посылает на сервер запросы на чтение
или изменение данных, которые формулируются на языке SQL. Сервер сам выполняет все
необходимые изменения или выборки, контролируя при этом целостность и согласован-
ность данных, и результаты в виде набора записей или кода возврата посылает на компь-
ютер клиента.
Недостатками же архитектуры с файловым сервером является то, что данные хра-
нятся в одном месте, а обрабатываются в другом. Это означает, что их нужно передавать
по сети, что приводит к очень высоким нагрузкам на сеть и, вследствие этого, резкому
снижению производительности приложения при увеличении числа одновременно работа-
ющих клиентов. Вторым важным недостатком такой архитектуры является децентрализо-
ванное решение проблем целостности и согласованности данных и одновременного до-
ступа к данным. Такое решение снижает надежность приложения.
Архитектура «клиент-сервер» позволяет устранить все указанные недостатки.
Кроме того, она позволяет оптимальным образом распределить вычислительную нагрузку
между клиентом и сервером, что также влияет на многие характеристики системы: стои-
мость, производительность, поддержку.
При разработке информационной системы будет использована технология клиент-
сервер. Во-первых, сервер оптимизирует выполнение функций обработки данных, что из-
бавляет от необходимости оптимизации рабочих станций. Сервер позволяет быстро по-
лучить результаты обработки запроса. Во-вторых, поскольку рабочие станции не обраба-
тывают все промежуточные данные, существенно снижается нагрузка на сеть. Предо-
ставляется возможность ведения журнала операций, в котором автоматически регистри-
руются все прошедшие транзакции что, в свою очередь, поможет быстрому восстановле-
нию системы при аппаратных сбоях. Данная технология организуется проще, и оборудо-
вание для её организации вполне приемлемо по стоимости приобретения.
Таким образом, проектируемая система с технической точки зрения будет представ-
лять собой набор объединенных в единую сеть ЭВМ – клиентов, с которых при помощи
33
установленного клиентского приложения будет осуществляться связь с базой данных, рас-
положенной на удаленном сервере, которая представлена на рис.7.
Рис.7 Конфигурация технического обеспечения ИС
Существует ряд требований к рабочим местам пользователей, реализация которых су-
щественно повысит быстродействие системы в целом.
Для функционирования разрабатываемой ИС была выбрана следующая конфигура-
ция персональных компьютеров для клиентов:
− процессор – Intel core 2 duo 2.2 GHz;
− память - от 4 Gb;
− жесткий диск от 200 Gb;
− CD-ROM - от 48x;
− Монитор - 19” Samsung SyncMaster;
− принтер HP LaserJet 1100;
− клавиатура и мышь Genius.;
− операционная система – Windows 7/8/8.1;
− сервер СУБД - SQL Server Management Studio Express;
− наличие средств информационной безопасности данных.
34
В качестве активного оборудования ЛВС используется управляемый
коммутатор 2-го уровня DES-1210-28 фирмы D-Link.
Коммутатор поддерживает полнодуплексный режим передачи данных и ори-
ентирован на применение в топологии «звезда».
Серия коммутаторов D-Link DES-1210 включает в себя модернизированные
коммутаторы семейства Web Snnart, объединяющие функции расширенного управ-
ления и безопасности, хорошую масштабируемость и производительность.
Модель DES-1210-28 поддерживает функцию Auto Voice VLAN, позволяю-
щую устанавливать первоочередной приоритет для пакетов голосовой связи и обес-
печивать бесперебойную работу приложения VoIP (передача голоса по сети), авто-
матическое определение NNDI/NNDIX, что исключает проблему применения крос-
сированных кабелей либо портов UpLink и делает подключение коммутатора весьма
необременительным.
Расширение стандартных функций 2-го уровня включает в себя IGNNP
Snooping, Spanning Tree (алгоритм отставного дерева), Port NNirroring и Link
Aggregation Control Protocol (LACP), а управление потоком IEEE 802.3x позволяет
напрямую подключить коммутатор к серверу для быстрой и надежной передачи дан-
ных.
2. ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл - это непрерывный процесс, который начинается с момента
принятия решения о необходимости его создания и заканчивается в момент его пол-
ного изъятия из эксплуатации. Среди наиболее известных стандартов можно выде-
лить следующие:
35
ГОСТ 34.601-90 - распространяется на автоматизированные системы и уста-
навливает стадии и этапы их создания. Кроме того, в стандарте содержится описание
содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стан-
дарте, в большей степени соответствуют каскадной модели жизненного цикла.
ISO/IEC 12207 - стандарт на процессы и организацию жизненного цикла. Рас-
пространяется на все виды заказного ПО. Стандарт не содержит описания фаз, ста-
дий и этапов.
Custom Development Method (методика Orаcle) по разработке прикладных ин-
формационных систем - технологический материал, детализированный до уровня за-
готовок проектных документов, рассчитанных на использование в проектах с при-
менением Orаcle. Применяется CDM для классической модели ЖЦ (предусмотрены
все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fаst
Trаck) или "облегченного подхода", рекомендуемых в случае малых проектов.
Rаtionаl Unified Process (RUP) предлагает итеративную модель разработки,
включающую четыре фазы: начало, исследование, построение и внедрение. Каждая
фаза может быть разбита на этапы (итерации), в результате которых выпускается
версия для внутреннего или внешнего использования. Прохождение через четыре
основные фазы называется циклом разработки, каждый цикл завершается генера-
цией версии системы. Если после этого работа над проектом не прекращается, то
полученный продукт продолжает развиваться и снова минует те же фазы. Суть ра-
боты в рамках RUP - это создание и сопровождение моделей на базе UML .
Microsoft Solution Frаmework (MSF) сходна с RUP, так же включает четыре
фазы: анализ, проектирование, разработка, стабилизация, является итерационной,
предполагает использование объектно-ориентированного моделирования. MSF в
сравнении с RUP в большей степени ориентирована на разработку бизнес-приложе-
ний.
Extreme Progrаmming (XP). Экстремальное программирование (самая новая
среди рассматриваемых методологий) сформировалось в 1996 году. В основе мето-
дологии командная работа, эффективная коммуникация между заказчиком и испол-
нителем в течение всего проекта по разработке ИС, а разработка ведется с использо-
ванием последовательно дорабатываемых прототипов.[15]
36
При выборе стандарта основным определяющим фактором является более
полное и подробное описание работ на стадиях и этапах разработки АС(автоматизи-
руемых систем). Стандарт ISO/IEC 12207 не содержит подробное описание работ на
разных стадиях и этапах разработки АС. Стандарт CDM рассчитан на использование
в проектах с применением Orаcle технологий, который в данном проекте не исполь-
зуются. Стандарт MSF, как было ранее сказано, в большей степени ориентирован на
разработку бизнес-приложений. Стандарт XP ориентирован на командную работу.
В данном проекте будет использоваться ГОСТ 34.601-90, так как он содержит опи-
сание работ на каждом этапе разработки АС.
Далее произведем выбор стратегии внедрения разработанной системы. В
настоящий момент выделяется четыре стратегии внедрения информационной си-
стемы:
• Параллельная стратегия - для случая, когда старую работающую систему
необходимо заменить новой;
• Скачок – эта стратегия подразумевает резкий переход от одной системы авто-
матизации к другой;
• Опытная эксплуатация "пилотного проекта - это тактика "скачка", но приме-
няемая к ограниченному числу изделий, наиболее успешна в малом участке
деятельности;
• Узкое место - при внедрении "узкого места" план внедрения выполняется
только для "узкого места" и для людей, работающих в нем.
Исходя из описания и условий деятельности компании, а также особенностей
разрабатываемой информационной системы, в качестве стратегии внедрения была
выбрана стратегия Опытная эксплуатация пилотного проекта, так как в этом случае
внедрение системы произойдет наиболее безболезненно.
Для проекта разработки АРМ менеджера по продажам наиболее подойдет кас-
кадная модель для разработки приложения из-за возможности контроля промежу-
точных фаз.
37
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Любой сложный проект, а особенно проект разработки программного обеспе-
чения, содержит в себе много неопределенных моментов, которые влекут за собой
риски реализации проекта [10].
Управление рисками заключается в их раннем выявлении и разработке мер,
либо полностью предотвращающих их возникновение, либо минимизирующих их
последствия.
В настоящее время существует три общепринятых стратегии управления рис-
ками:
− Избегание рисков – проект реорганизуется таким образом, чтобы исключить
возможность возникновения рисков;
− Делегирование рисков – проект реорганизуется таким образом, чтобы перело-
жить риски на третью сторону (заказчика, банки, вендора и т.п.);
− Принятие рисков – риски признаются в качестве неизбежной составляющей
проекта, проводится постоянный мониторинг симптомов их наступления, по-
стоянно корректируется план действий в случае наступления рисков [11].
Различают две основные категории рисков – прямые и опосредованные. На
прямые риски проектная команда может каким-то образом повлиять, а опосредован-
ные риски команда контролировать не может в принципе.
Риски делятся на следующие основные виды:
1. Ресурсные риски:
− организация (выполняла ли организация прежде проекты такого масштаба, су-
ществует ли формальный процесс разработки программного обеспечения и
т.п.);
− финансирование (полностью ли обеспечено финансирование проекта, фикси-
рована ли стоимость проекта или она является предметом для обсуждения,
точно ли выполнена оценка затрат и т.п.);
− люди (достаточно ли людей для выполнения проекта, обладают ли они необхо-
димыми навыками и опытом, работали ли они вместе раньше и т.п.);
− время (реалистичен ли план проекта, насколько критичной является дата окон-
чания проекта и т.п.);
38
− бизнес (что произойдет, если конкурент выйдет на рынок первым, выгода, по-
лученная от реализации проекта больше, чем затраты на него, что произойдет,
если ключевые поставщики не смогут выполнить свои обязательства и т.п.).
2. Технические риски:
− область действия (scope) проекта (могут ли быть измерены критерии успеш-
ного завершения проекта, требования стабильны и хорошо поняты, область
действия жестко фиксирована или может расширяться в будущем и т.п.);
− технологии (отлажена ли применяемая технология или она только была разра-
ботана, и т.п.) [12];
− внешние зависимости (зависит ли проект от других параллельных проектов, за-
висит ли успех проекта от внешних поставщиков технологий и/или продуктов
и т.п.).
В данном проекте можно выделить следующие основные риски на каждом
этапе жизненного цикла (таблица 8).
Таблица №8
Основные риски на этапах жизненного цикла информационной системы
Этап
Риск
Мероприятия
Заказ
Несоответствие выделенного бюд-
жета масштабу проекта
Переговоры по увеличению
бюджета или отказ от участия
в проекте
Заказ
Неформализуемая задача (невоз-
можно автоматизировать те или
иные бизнес-процессы или стои-
мость такой автоматизации превы-
сит ожидаемую выгоду)
Пересмотреть область дей-
ствия проекта с целью выде-
ления отдельных задач, под-
дающихся автоматизации.
Провести детальный анализ
бизнес-процессов и предло-
жить комплекс мероприятий
по их реорганизации.
39
Продолжение таблицы №8
Проектиро-
вание
- неправильное определение рамок
и масштабов проекта;
- проектирование ошибочных
функций и интерфейсов будущей
системы;
- выбор неправильных технологий
и методов решения поставленных
задач;
- несоблюдение требований заказ-
чика при проектирование будущей
системы или постоянное измене-
ние требований.
- обеспечение стабильности
границ проекта, определен-
ных на начальном этапе,
вплоть до окончания проекта;
- качественное планирование
работ;
- своевременная идентифика-
ция проектных рисков и раз-
работка рекомендаций по
снижению рисков;
- обеспечение проекта необ-
ходимыми ресурсами;
- обязательное утверждение и
согласование по проектным
решениям
Разработка
Недостаточно ресурсов для вы-
полнения комплексного и нагру-
зочного тестирования
Заключить договор со специа-
лизированной организацией
на выполнение ею этих работ.
Недостаточно опыта у персонала
заказчика, который будет эксплуа-
тировать систему
Предоставить заказчику
услуги собственного специа-
листа для первоначального
сопровождения системы и по-
степенного обучения персо-
нала заказчика.
Внедрение
- увеличение нагрузки на персо-
нал;
- несогласованность действий пер-
сонала исполнителя и сотрудников
предметных областей
- проведение обучения персо-
нала заказчика работы с си-
стемой;
- составление плана внедре-
ния ИС
40
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Для ограничения использования беспроводной сети она защищена шифрова-
нием по протоколу WEP2, а также настроена фильтрация клиентов по MAC-адресам.
Кроме того, используется система видеонаблюдения, система пожаротушения
и система контроля и управления доступом.
В компании разработана и применяется политика безопасности.
Целями политики безопасности являются:
• сохранение конфиденциальности критичных информационных ресур-
сов;
• обеспечение непрерывности доступа к информационным ресурсам
Компании для поддержки бизнес деятельности;
• защита целостности деловой информации с целью поддержания воз-
можности по оказанию услуг высокого качества и принятию эффективных управ-
ленческих решений;
• повышение осведомленности пользователей в области рисков, связан-
ных с информационными ресурсами;
• определение степени ответственности и обязанностей сотрудников по
обеспечению информационной безопасности.
Руководители подразделений должны обеспечить регулярный контроль за со-
блюдением положений политики. Кроме того, должна быть организована периоди-
ческая проверка соблюдения информационной безопасности с последующим пред-
ставлением отчета по результатам указанной проверки руководству.
Требования политики распространяются на всю информацию и ресурсы обра-
ботки информации. Соблюдение политики обязательно для всех сотрудников (как
постоянных, так и временных). В договорах с третьими лицами, получающими до-
ступ к информации, должна быть оговорена обязанность третьего лица по соблюде-
нию требований политики безопасности.
К основным задачам администратора разрабатываемой информационной си-
стемы на платформе «1С: Предприятие» в условиях относят:
- работу с пользовательскими учетными записями (введение новых учетных за-
писей), изменение уровня доступа к системе, удаление пользователя из системы;
41
- создание групповых политик (назначение групповых прав доступа);
- макроооперации с информационными базами (установка обновлений, тести-
рование БД, реорганизация, сжатие и др.);
- резервное копирование базы данных;
- восстановление баз данных;
- организация хранения копий баз данных;
- разработка нормативных документов в области функционала администратора
БД.
Эффективное управление пользовательскими учетными записями позволит по-
высить защищенность системы, снизить вероятность ошибок пользователей вслед-
ствие влияния человеческого фактора, позволить реализовать протоколирование
действий пользователей.
Рассмотрим организацию технологии администрирования информационных
ресурсов разрабатываемой в ВКР информационной системы.
Основными методами администрирования ПО «1С: Предприятие» является ад-
министрирование на уровне программного обеспечения (регулирует доступ к режи-
мам работы программного обеспечения), а также администрирование на уровне кон-
троллера домена (регулирует доступ к ПО через доменные учетные записи пользо-
вателей).
Обязанности администратора ПО «1С:Предприятие» возложены на ИТ-специ-
алиста.
На рис. 11 приведена схема документооборота администрирования ПО «1С:
Предприятие».
Начальник отдела
Заявка на доступ
Администратор БД
Таблицы доступа
к БД, Профиль
доступа
Парольная
карточка