56
«C++ Builder» представляет собой некую интеграцию «Borland Delphi» и
«С++»: т.е. используется та же среда программирования (RAD), взятая из «С++»
и библиотека визуальных компонентов (VCL), взятая из «Borland Delphi». В
этом и заключается основной недостаток этого языка - библиотека VCL, реали-
зованная в «Borland Delphi», существенно увеличивает размер исполняемых
файлов. Преимущество «C++ Builder», по сравнению с предшественниками, -
улучшенная версия объектной модели [21].
«C#» – язык, где сочетаются простота «Visual Basic» с мощью «C++».
Синтаксис языка аналогичен «C++», но более мощный, безопасный и простой.
«C#» поддерживает работу с разными типами данных, статическую типизацию,
перегрузку операторов и многое другое. Данный язык может применяться как
при разработке приложений, так и для создания сайтов. В «C#», также как и у
его оппонентов, есть свои недостатки, среди которых следует выделить моно-
платформенность (разработка приложений исключительно для Windows) и низ-
кое быстродействие [21].
На рисунке 18 приводится экспертная оценка возможностей рассматрива-
емых систем: «Visual Basic» (VB), «Borland Delphi» (Del), «C++» , «C++ Builder»
(CB) и C# (по десятибалльной шкале) [21].
Рис. 18. Экспертная оценка основных средств разработки приложений
7
5
4
5
5
6
4
5
7
9
0
4
7
8
6
5
3
6 5
8
6
9
8
7
8
8
8
6
5
3
6
5
8
6
8
8
7
8
8
9
8
6
5
7
5
7
6
9 8
7
7
8
0
5
10
15
20
25
30
35
40
45
C#
CB
C++
Del
VB
57
Таким образом, подводя итоги анализа языков программирования, стано-
вится очевидным, что каждый из них может быть успешно использован для раз-
работки, разрабатываемой в данной работе, информационной системы. Поэтому,
выбор среды программирования будет производиться на основе опыта, уровня
знаний и предпочтений разработчика, т.к. они способны существенным образом
отразиться и на качестве реализуемого программного продукта.
Для разработчика, наиболее понятной и удобной оказалась среда разра-
ботки «Borland Delphi». Наличие в интернете множества форумов по данной те-
матике, бесплатных обучающих ресурсов (книг, видео-уроков), обращение к ко-
торым поможет разобраться с возникшими в процессе программирования вопро-
сами, только доказывают правильность принятого решения.
1.4.3. Обоснование проектных решений по техническому обеспечению
Техническое обеспечение – это комплекс технических средств, необходи-
мых для функционирования проектируемой ИС [48].
В состав технического обеспечения обычно входят: персональные компь-
ютеры работников, сервер, соединительные линии ЛВС, и принтеры.
В данной работе стоит задача – использовать для внедрения разрабатыва-
емой системы уже имеющиеся на предприятии технические средства. В связи с
этим, проектные решения должны быть адаптированы к используемому техни-
ческому обеспечению.
Такой подход связан с экономическими соображениями, т.к. покупка но-
вого железа и установка на нем программных обеспечения может потребовать
значительных финансовых затрат со стороны ООО «СпекТек».
Технические характеристики серверов E220-M5, перечисленные ранее в
таблице 1, могут быть использованы для реализации внедряемого нами решения.
Используемая модель сервера способна наращивать свою производительность
для выполнения автоматизируемой задачи без ущерба для других выполняемых
им задач, в связи чем, принято решение, что сервер не требует модернизации.
58
Так как разрабатываемая система будет работать на основе клиент-
серверной технологии, то все вычисления будут производиться на стороне сер-
вера, следовательно, системные требования к персональным компьютерам ми-
нимальны.
При выборе типа ЭВМ необходимо руководствоваться рядом таких харак-
теристик, как: надежность, стоимость, производительность, объем памяти и дру-
гие.
В настоящее время в мире существуют несколько классов ЭВМ: большие,
мини- и микро-ЭВМ
Для решения задач, поставленных в данной работе, наиболее подходят
ПЭВМ. Они имеют невысокую стоимость, подходящие габариты и удовлетво-
ряют требованиям производительности, надежности, стоимости и т.п.
При выборе ПЭВМ необходимо учесть следующие характеристики:
- тактовая частота процессора;
- объем оперативной памяти;
- объем жесткого диска.
В настоящее время на рабочих местах работников организации уже уста-
новлены ПЭВМ имеющие следующие характеристики:
- процессор «Intel Core i5-4200U» с частотой 1.6 ГГц;
- оперативная память объемом, 4 Гб;
- жесткий диск объемом 1Тб.
Для печати отчетов и выходных документов используются принтеры, сов-
местимые с используемыми компьютерами.
Выбор соединительных линий ЛВС производится по оценке их пропуск-
ной способности. В разрабатываемой системе не будет происходить передача
объемного трафика, как например, при обмене видео-файлами, поэтому особых
требований к пропускной способности каналов связи не предъявляется.
Текущая пропускная способность линий ЛВС в ООО «СпекТек» составля-
ет 100 мбит/сек., чего достаточно для разрабатываемой ИС.
59
II ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл ИС – это период времени с момента принятия решения о
необходимости создания ИС и заканчивая полным изъятием ИС из эксплуата-
ции.
В наше время используются следующие стандарты жизненного цикла ИС:
ГОСТ 34, ISO 12207, ISO 15288, MSF, RUP, COBIT, Orаcle CDM, XP.
Стандарт «ГОСТ 34» содержит описание содержания работ на каждом
этапе. Стадии и этапы создания системы в большей степени соответствуют кас-
кадной модели жизненного цикла. Данный стандарт потерял свою значимость в
настоящее время: многие процессы отражены недостаточно полно, а некоторые
положения устарели.
Стандарт «ISO 12207» распространяется на все виды заказного ПО. Стан-
дарт не привязан к определенной модели ЖЦ и не содержит описания фаз, ста-
дий и этапов. Стандарт описывает структуру процессов жизненного цикла ИС,
не уточняя, как реализовать задачи, включенные в эти процессы.
Стандарт «ISO15288» применим для любого класса систем. Стандарт
предлагает следующие стадии создания ИС: формирование концепции, разра-
ботка, реализация, эксплуатация, поддержка, снятие с эксплуатации.
Стандарт Microsoft Solutions Frаmework (MSF) включает следую-
щие основные фазы процесса разработки: выработка концепции, планирование,
разработка, стабилизация, внедрение.
Стандарт Rаtionаl Unified Process (RUP) предлагает итеративную модель
разработки, включающую четыре фазы: начало, исследование, построение,
внедрение.
Стандарт Custom Development Method (методика Orаcle) – данный стан-
дарт разработан специально для продуктов компании Orаcle и состоит из следу-
ющих этапов: стратегия, анализ, проектирование, реализация, внедрение, экс-
плуатация.
60
Стандарт «COBIT» может быть описан следующим образом. Разработчик
начинает кодирование системы с самого первого дня ее разработки, не занима-
ясь серьезным проектированием. Все ошибки и недоработки обнаруживаются,
как правило, к концу кодирования и требуют исправления через повторное ко-
дирование.
В основе стандарта «XP» (экстремальное программирование) лежит тес-
ное сотрудничество с заказчиком в течение всего срока проектирования ИС.
Стандарт «ГОСТ 34» потерял свою значимость в настоящее время: мно-
гие процессы отражены недостаточно полно, а некоторые положения устарели.
В стандартах «Методика Orаcle», «RUP», «MSF» и «XP» не приводится
структура и описание технической документации по проекту, поэтому для раз-
работки ИС учета работы с клиентами для ООО «СпекТек» был выбран стандарт
ISO12207.
Стандарт «ISO12207» не требует использования какой-либо конкретной
модели жизненного цикла, однако он требует, чтобы в каждом проекте опреде-
лялась подходящая модель жизненного цикла, предпочтительно та, которая уже
выбиралась организацией для применения в различных проектах.
В настоящее время используются следующие модели жизненного цикла:
- каскадная модель предусматривает последовательное выполнение всех
этапов проекта в строго установленном порядке. Переход на следующий этап
производится только после завершения работ на предыдущем этапе;
- поэтапная модель предусматривает разработку ИС путем проведения
промежуточного контроля работ на каждом этапе; время жизни каждого из эта-
пов растягивается на весь период разработки.
- спиральная модель основана на проведении тщательного анализа и про-
ектирования предметной области на начальных этапах. На каждом этапе проис-
ходит создание очередной версии продукта, уточняются требования, определя-
ется качество ИС, и планируются работы для следующего этапа.
Для разработки проекта была выбрана каскадная модель жизненного цик-
ла ИС, состоящая из следующих этапов: системный анализ; анализ требований;
проектирование; кодирование; тестирование; внедрение и сопровождение.
61
На этапе системного анализа определяются системные требования, а так-
же то, каким образом будут распределены ресурсы организации с целью их со-
ответствия поставленным требованиям.
На этапе анализа требований к продукту производится анализ существу-
ющих недостатков учета и разработка требований к ИС.
Этап проектирования определяет, каким образом функции ПО должны
применяться при реализации проекта, определяет и документально обосновыва-
ет алгоритмы для каждого компонента. Эти алгоритмы в последствии будут пре-
образованы в код.
На этапе кодирования выполняется преобразование алгоритмов, опреде-
ленных на этапе проектирования, в готовое ПО.
На этапе тестирования выполняется проверка каждого закодированного
модуля на наличие ошибок.
Внедрение предполагает запуск ПО в производство. На данном этапе так-
же могут вноситься правки в систему.
Существуют четыре стратегии внедрения ИС:
1) Параллельная стратегия применяется когда старая ИС заменяется но-
вой, при этом пока новая ИС не будет полноценно существовать, используются
обе версии ИС (и старая и новая).
2) Скачок предполагает резкий переход от одной системы к другой. При
данном подходе, необходимо чтобы персонал компании был хорошо подготов-
лен к использованию новой ИС, иначе это может привести к неблагоприятным
последствиям.
З) Опытная эксплуатация пилотного проекта напоминает стратегию скач-
ка, но в данном случае новая система применяется не сразу во всех подразделе-
ниях компании, а в определенном отделе.
4) Узкое место предполагает внедрение ИС в наиболее проблемное под-
разделение организации. Пpи стратегии узкого места объем работ уменьшается и
внедрение завершается в более короткие сроки.
62
Анализ стратегий внедрения позволяет сделать вывод, что для внедрения
проектируемой ИС в ООО «СпекТек» целесообразно использовать стратегию
«пилотный проект», т.к. такoй пoдxoд наибoлее надeжeн и cнижаeт риски.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их
описание
При реализации проекта ИС могут возникнуть проблемы или сложности,
которые могут прервать или же сорвать процесс разработки системы. Поэтому
очень важно заранее оценить риски, возникновение которых возможно на всех
этапах жизненного цикла ИС и предусмотреть пути их устранения или миними-
зации.
Рассмотрим наиболее вероятные риски на этапах жизненного цикла
информационной системы в соответствии с выбранной каскадной моделью жиз-
ненного цикла.
На этапе системного анализа есть риск запланировать некорректные сроки
разработки проекта, указать низкую стоимость, недооценить состав участников
проекта и т.п.
Риски на данном этапе устраняются более тщательным планированием
сроков разработки с учетом ее участников, например, составить диаграмму Ган-
та. На основе данных о сроках разработки и состава участников проекта необхо-
димо оценить стоимость реализации системы.
На этапе анализа требований к программному продукту есть риск запла-
нировать такие функциональные возможности ИС, реализовать которые впо-
следствии будет очень сложно либо невозможно.
Для предотвращения риска на данном этапе необходимо адекватно оцени-
вать свои возможности и не «прыгать выше головы. При описании функций си-
стемы достаточно представить перечень базовых задач, которые будет решать
проектируемая система. По мере реализации проекта, систему можно расширять
новыми возможностями.
На этапе проектирования есть риск некорректного описания алгоритмов,
методики расчётов и т.п. Ошибки, допущенные на данном этапе, могут быть пе-
ренесены реализуемый проект, если вовремя не устранить их.
63
Для устранения данного риска необходимо производить контроль полу-
ченных результатов на каждом этапе проектирования и сверять либо перепрове-
рять расчеты.
На этапе кодирования есть вероятность возникновения риска отсутствия в
выбранной среде разработки инструментов, необходимых для реализации проек-
та в соответствии с требованиями ТЗ.
Данного риска можно избежать, если заранее ознакомиться с возможно-
стями выбранной среды разработки.
На этапе тестирования может возникнуть риск неполного тестирования,
когда тестовые данные подобраны не для всех модулей программы.
Такой риск можно устранить корректным составлением тестового набора
данных или путем повторного тестирования.
Фаза внедрения может сопровождаться риском неготовности или нежела-
нию персонала заказчика к работе с новым программным продуктом. Это может
затянуть процесс внедрения системы. Также есть риск обнаружения, в процессе
внедрения системы, новых ошибок или сбоев, устранение которых может занять
немало времени.
Данный вид риска можно минимизировать, создав для работников компа-
нии короткие видео-уроки по работе с программой, которые они смогут про-
сматривать в свободное время. Таким образом, персонал заказчика сможет уви-
деть, как упростится их работа с внедрением системы.
Второй риск на данном этапе, связанный с обнаружением сбоев и ошибок
в программе, практически неизбежен, но его можно минимизировать при тща-
тельном планировании работ на всех предыдущих этапах жизненного цикла ИС.
2.1.3. Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
Меры по защите информации в разрабатываемой информационной
системе можно разделить на 2 группы:
64
- средства защиты информации в ИС от внутренних угроз;
- средства защиты информации от внешних угроз.
Для защиты от внутренних угроз в системе используется политика разгра-
ничения прав доступа. Описание политики разграничения прав доступа к моду-
лям программы представлено в таблице 4.
Таблица 4
Разграничение прав доступа к модулям ИС
Группы пользователей
Модуль
«Пользователь»
Модуль
«Ответственный»
Модуль
«Исполнитель»
Клиенты
Полный
Нет
Нет
Начальник отдела
Ограничен
Полный
Ограничен
Технические специалисты
Нет
Нет
Полный
Описание политики разграничения прав доступа относительно объектов
базы данных представлено в таблице 5.
Таблица 5
Разграничение прав доступа к объектам БД
Объекты БД
Клиенты
Начальник отдела
Технические
специалисты
Сотрудники
Чтение
Полный
Ограничен
Клиенты
Нет
Полный
Ограничен
Пользователи
Ограничен
Полный
Полный
Темы заявок
Чтение
Полный
Нет
Приоритеты
Чтение
Полный
Нет
ПО
Чтение
Полный
Нет
Заявки
Полный
Ограничен
Полный
Ход исполнения
Полный
Ограничен
Полный
Вложения
Полный
Ограничен
Полный
Задачи
Нет
Ограничен
Полный
Операции
Нет
Ограничен
Полный
Используемые в компании средства защиты от внешних угроз описаны в
пункте 1.2.4. данной работы.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Информационная модель – это набор правил и операций, необходимых
65
для выявления и изучения взаимосвязей между данными в конкретной предмет-
ной области.
Грамотно построенная информационная модель может служить основой
для построения базы данных проектируемой ИС.
Чтобы построить информационную модель какого-либо бизнес-процесса,
необходимо выявить перечень входных и выходных документов, участвующих в
этом процессе. На основе этих данных можно определить перечень таблиц про-
ектируемой БД, т.е. построить инфологическую модель.
Инфологическая модель разрабатываемой системы приведена на рисунке
19.
Клиенты
Вложения
Приоритеты Темы заявок
Пользователи
Ход
исполнения
Заявки
Принадлежат 1
Имеют
Указывается
Состоят из
Состоят из
Создают
M
1
1
M
М
1
1
М
1
M
Название ПО
Содержат
1
M
M
Задачи
Сожержат
М
1
Операции
Состоят из M
1
Сотрудники
Обрабатывают
1
1
Рис. 19. Инфологическая модель
Инфологическая модель предметной области - это наши знания о пред-
метной области и логических связях между данными, выраженные при помощи
специализированных графических средств. В качестве такого графического
средства, выбран свободный редактор диаграмм «Visio 2010».