31
Существует ряд требований к рабочим местам пользователей, реализация которых
существенно повысит быстродействие системы в целом.
Для функционирования разрабатываемой ИС была выбрана следующая конфигура-
ция персональных компьютеров для клиентов:
− процессор – 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;
− наличие средств информационной безопасности данных.
В качестве активного оборудования ЛВС используется управляемый
коммутатор 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 позволяет
напрямую подключить коммутатор к серверу для быстрой и надежной передачи
данных.
32
2. ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл - это непрерывный процесс, который начинается с момента
принятия решения о необходимости его создания и заканчивается в момент его
полного изъятия из эксплуатации. Среди наиболее известных стандартов можно
выделить следующие:
ГОСТ 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 в
33
сравнении с RUP в большей степени ориентирована на разработку бизнес-
приложений.
Extreme Progrаmming (XP). Экстремальное программирование (самая новая
среди рассматриваемых методологий) сформировалось в 1996 году. В основе мето-
дологии командная работа, эффективная коммуникация между заказчиком и ис-
полнителем в течение всего проекта по разработке ИС, а разработка ведется с ис-
пользованием последовательно дорабатываемых прототипов.[15]
При выборе стандарта основным определяющим фактором является более
полное и подробное описание работ на стадиях и этапах разработки
АС(автоматизируемых систем). Стандарт ISO/IEC 12207 не содержит подробное
описание работ на разных стадиях и этапах разработки АС. Стандарт CDM рассчи-
тан на использование в проектах с применением Orаcle технологий, который в дан-
ном проекте не используются. Стандарт MSF, как было ранее сказано, в большей
степени ориентирован на разработку бизнес-приложений. Стандарт XP ориентиро-
ван на командную работу. В данном проекте будет использоваться ГОСТ 34.601-
90, так как он содержит описание работ на каждом этапе разработки АС.
Далее произведем выбор стратегии внедрения разработанной системы. В
настоящий момент выделяется четыре стратегии внедрения информационной си-
стемы:
• Параллельная стратегия - для случая, когда старую работающую систему
необходимо заменить новой;
• Скачок – эта стратегия подразумевает резкий переход от одной системы ав-
томатизации к другой;
• Опытная эксплуатация "пилотного проекта - это тактика "скачка", но приме-
няемая к ограниченному числу изделий, наиболее успешна в малом участке
деятельности;
• Узкое место - при внедрении "узкого места" план внедрения выполняется
только для "узкого места" и для людей, работающих в нем.
Исходя из описания и условий деятельности компании, а также особенно-
стей разрабатываемой информационной системы, в качестве стратегии внедрения
была выбрана стратегия Опытная эксплуатация пилотного проекта, так как в этом
случае внедрение системы произойдет наиболее безболезненно.
34
Для проекта разработки АРМ личного кабинета консультанта по недвижи-
мости наиболее подойдет каскадная модель для разработки приложения из-за воз-
можности контроля промежуточных фаз.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Любой сложный проект, а особенно проект разработки программного обес-
печения, содержит в себе много неопределенных моментов, которые влекут за со-
бой риски реализации проекта [10].
Управление рисками заключается в их раннем выявлении и разработке мер,
либо полностью предотвращающих их возникновение, либо минимизирующих их
последствия.
В настоящее время существует три общепринятых стратегии управления
рисками:
− Избегание рисков – проект реорганизуется таким образом, чтобы исключить
возможность возникновения рисков;
− Делегирование рисков – проект реорганизуется таким образом, чтобы пере-
ложить риски на третью сторону (заказчика, банки, вендора и т.п.);
− Принятие рисков – риски признаются в качестве неизбежной составляющей
проекта, проводится постоянный мониторинг симптомов их наступления, по-
стоянно корректируется план действий в случае наступления рисков [11].
Различают две основные категории рисков – прямые и опосредованные. На
прямые риски проектная команда может каким-то образом повлиять, а опосредо-
ванные риски команда контролировать не может в принципе.
Риски делятся на следующие основные виды:
1. Ресурсные риски:
− организация (выполняла ли организация прежде проекты такого масштаба,
существует ли формальный процесс разработки программного обеспечения и
т.п.);
− финансирование (полностью ли обеспечено финансирование проекта, фикси-
рована ли стоимость проекта или она является предметом для обсуждения,
точно ли выполнена оценка затрат и т.п.);
− люди (достаточно ли людей для выполнения проекта, обладают ли они необ-
ходимыми навыками и опытом, работали ли они вместе раньше и т.п.);
35
− время (реалистичен ли план проекта, насколько критичной является дата
окончания проекта и т.п.);
− бизнес (что произойдет, если конкурент выйдет на рынок первым, выгода, по-
лученная от реализации проекта больше, чем затраты на него, что произойдет,
если ключевые поставщики не смогут выполнить свои обязательства и т.п.).
2. Технические риски:
− область действия (scope) проекта (могут ли быть измерены критерии успеш-
ного завершения проекта, требования стабильны и хорошо поняты, область
действия жестко фиксирована или может расширяться в будущем и т.п.);
− технологии (отлажена ли применяемая технология или она только была раз-
работана, и т.п.) [12];
− внешние зависимости (зависит ли проект от других параллельных проектов,
зависит ли успех проекта от внешних поставщиков технологий и/или продук-
тов и т.п.).
В данном проекте можно выделить следующие основные риски на каждом
этапе жизненного цикла (таблица 8).
Таблица №8
Основные риски на этапах жизненного цикла информационной системы
Этап
Риск
Мероприятия
Заказ
Несоответствие выделенного бюд-
жета масштабу проекта
Переговоры по увеличению
бюджета или отказ от участия
в проекте
Заказ
Неформализуемая задача (невоз-
можно автоматизировать те или
иные бизнес-процессы или стои-
мость такой автоматизации превы-
сит ожидаемую выгоду)
Пересмотреть область дей-
ствия проекта с целью выде-
ления отдельных задач, под-
дающихся автоматизации.
Провести детальный анализ
бизнес-процессов и предло-
жить комплекс мероприятий
по их реорганизации.
36
Продолжение таблицы №8
Проектиро-
вание
- неправильное определение рамок
и масштабов проекта;
- проектирование ошибочных
функций и интерфейсов будущей
системы;
- выбор неправильных технологий
и методов решения поставленных
задач;
- несоблюдение требований заказ-
чика при проектирование будущей
системы или постоянное изменение
требований.
- обеспечение стабильности
границ проекта, определенных
на начальном этапе, вплоть до
окончания проекта;
- качественное планирование
работ;
- своевременная идентифика-
ция проектных рисков и раз-
работка рекомендаций по
снижению рисков;
- обеспечение проекта необхо-
димыми ресурсами;
- обязательное утверждение и
согласование по проектным
решениям
Разработка
Недостаточно ресурсов для выпол-
нения комплексного и нагрузочно-
го тестирования
Заключить договор со специа-
лизированной организацией на
выполнение ею этих работ.
Недостаточно опыта у персонала
заказчика, который будет эксплуа-
тировать систему
Предоставить заказчику услу-
ги собственного специалиста
для первоначального сопро-
вождения системы и посте-
пенного обучения персонала
заказчика.
Внедрение
- увеличение нагрузки на персонал;
- несогласованность действий пер-
сонала исполнителя и сотрудников
предметных областей
- проведение обучения персо-
нала заказчика работы с си-
стемой;
- составление плана внедрения
ИС
37
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Для ограничения использования беспроводной сети она защищена шифрова-
нием по протоколу WEP2, а также настроена фильтрация клиентов по MAC-
адресам.
Кроме того, используется система видеонаблюдения, система пожаротуше-
ния и система контроля и управления доступом.
В компании разработана и применяется политика безопасности.
Целями политики безопасности являются:
• сохранение конфиденциальности критичных информационных ресур-
сов;
• обеспечение непрерывности доступа к информационным ресурсам
Компании для поддержки бизнес деятельности;
• защита целостности деловой информации с целью поддержания воз-
можности по оказанию услуг высокого качества и принятию эффективных управ-
ленческих решений;
• повышение осведомленности пользователей в области рисков, связан-
ных с информационными ресурсами;
• определение степени ответственности и обязанностей сотрудников по
обеспечению информационной безопасности.
Руководители подразделений должны обеспечить регулярный контроль за
соблюдением положений политики. Кроме того, должна быть организована перио-
дическая проверка соблюдения информационной безопасности с последующим
представлением отчета по результатам указанной проверки руководству.
Требования политики распространяются на всю информацию и ресурсы об-
работки информации. Соблюдение политики обязательно для всех сотрудников
(как постоянных, так и временных). В договорах с третьими лицами, получающими
доступ к информации, должна быть оговорена обязанность третьего лица по со-
блюдению требований политики безопасности.
38
Для ограничения использования беспроводной сети она защищена шифрова-
нием по протоколу WEP2, а также настроена фильтрация клиентов по MAC-
адресам.
Кроме того, используется система видеонаблюдения, система пожаротуше-
ния и система контроля и управления доступом.
Обязанности администратора ПО «1С: Предприятие» возложены на ИТ-
специалиста.
В таблице 11 приведена таблица разграничения прав групп пользователей к
информационной системе.
Таблица 11
Разграничение прав пользователей
Группы
пользователей
Нормативно-
справочная
информация
Транзакции
Аналитическая
отчетность
Менеджеры
поставщиков и
подрядчиков
Чтение/создани
е/удаление
Чтение/создание
/удаление
Права отсутствуют
Администраторы
ИС
Чтение/создани
е/удаление
Чтение/создание
/удаление
Чтение/создание/удал
ение
Топ-менеджеры
Чтение
Чтение
Полный
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Информационная модель представляет собой схему движения входных, про-
межуточных и результативных потоков и функций предметной области. Кроме то-
го, она объясняет, на основе каких входных документов и какой нормативно-
справочной информации происходит выполнение функций по обработке данных и
формирование конкретных выходных документов. Информационная модель пред-
ставлена на рис.9.
39
Рис.9 Информационная модель системы автоматизации предметной области
Информационная модель содержит 4 области:
1. Область входящей информации, в которой указаны документы, ин-
формация из которых используется в качестве входной, а также экранные формы
для ввода данной информации;
40
2. Область справочников системы, которая иллюстрирует состав спра-
вочников и таблиц информационной системы;
3. Область обработки информации, в которой показано, как входная ин-
формация учитывается в системе и в каких таблицах базы данных она сохраняется;
4. Область формирования результатной информации, в которой приведе-
ны экранные формы и выходные документы.
Пользователь системы первоначально заполняет справочники системы ис-
ходными данными, после чего система готова к работе. Используя входные дан-
ные, пользователь формирует содержание таблиц системы. При запросе результат-
ной информации с помощью соответствующих экранных форм хранящаяся в си-
стеме информация преобразуется в необходимый вид и представляется в виде ре-
зультатных документов, которые выводятся в виде экранных форм и могут быть
выведены на печать на твердый носитель.
2.2.2. Характеристика нормативно-справочной, входной и оперативной
информации
Создание фактографических экономических информационных систем начи-
нается с разработки нормативно-справочной информации и справочных классифи-
каторов.
Для внедряемой подсистемы СRM разработаны следующие справочники:
− Объекты
− Договора
− Клиенты
− Сотрудники
− Заказчики
Структура с характеристикми входных документов и файлов представлены в
таблице 2.1
Таблица 2.1