36
Для каждой заявки должны быть предусмотрены следующие статусы, ко-
торые будут давать пользователю возможность отслеживания:
1. Новая заявка.
2. Назначен специалист.
3. В работе.
4. Закрыто.
Перечисленные стадии прохождения заявки должны входить в состав
справочника «Статусы заявок».
Статусы прохождения заявок будут выставляться специалистами ИТ-
отдела.
1.4.2. Обоснование проектных решений по программному обеспечению
Информационные системы позволяют пользователям осуществлять сбор
и обработку данных. Для хранения данных используются базы данных. Разли-
чают следующие виды баз данных [20, стр. 125]:
1. Иерархические.
2. Сетевые.
3. Реляционные.
В настоящее время широко применяются реляционные базы данных в
связи со следующими факторами [11, стр. 69]:
• они обладают простотой, поскольку в реляционной модели данных
существует всего одна информационная конструкция, формализующая таблич-
ное представление данных.
• наличие теоретически обоснованных методов нормализации отноше-
ний позволяет получать базу данных с заданными характеристиками.
• независимость данных заключается в том, что при необходимости
внесения изменений в структуру реляционной базы данных, требуется внесение
минимальных изменений.
37
Помимо перечисленных достоинств, в организации уже используется ре-
ляционная СУБД. Поэтому, с целью минимизации затрат и конфликтов в про-
цессе интеграции, для разработки информационной системы будет использова-
на реляционная база данных.
Для управления реляционной базой данных используется реляционная
СУБД. На рынке широко представлены как коммерческие, так и бесплатные
СУБД. Наиболее востребованными на рынке являются следующие СУБД:
• Microsoft SQL Server;
• MySQL;
• PostgreSQL;
• IBM DB2;
• Oracle database.
СУБД IBM DB2 является кроссплатформенной, обеспечивает стабильную
работу базы данных. Недостатками системы являются высокая стоимость и
низкая производительность. СУБД Microsoft SQL Server обладает большим па-
кетом инструментов, стабильностью работы и низкими затратами на админи-
стрирование. Недостаток системы заключается в том, что она работает только
на платформе Windows. СУБД Oracle обладает высокой производительностью,
легкостью интегрирования приложений и устойчивостью к большим потокам
данных. Недостатком является высокая стоимость, необходимость приобрете-
ния мощного оборудования и персонала для поддержки. MySQL является сво-
бодно распространяемой реляционной СУБД. Гибкость СУБД MySQL обеспе-
чивается поддержкой большого количества типов таблиц: пользователи могут
выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск,
так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных за-
писей. Недостатком СУБД MySQL является то, что она не подходит для разра-
ботки крупномасштабных приложений.
Ввиду перечисленных свойств реляционных СУБД был сделан выбор в
пользу СУБД MySQL 5.6, поскольку эта СУБД является свободно распростра-
няемой, гибкой, поддерживает SQL (структурированный язык запросов), благо-
38
даря внутреннему механизму многопоточности MySQL имеет досточно высо-
кую производительность и подходит для создания малых и средних приложе-
ний.
В качестве операционной системы предполагается использование приоб-
ретенной ранее Windows Server 2012 которая является быстрой и надежной.
Для разработки информационной системы будет использован объектно-
ориентированный подход, поскольку он позволяет осуществлять конструирова-
ние из компонентов, обладающих простыми инструментами, что дает возмож-
ность абстрагироваться от деталей реализации. При этом данные и операции
вместе образуют определенную сущность, и они не «размазываются» по всей
программе, как это нередко бывает в случае процедурного программирования.
Использование локализации программного кода и данных улучшает нагляд-
ность и удобство сопровождения программного обеспечения.
В качестве языка программирования был выбран язык программирования
PHP, который является скриптовым языком общего назначения, применяемым
для разработки WEB-приложений.
Разработка информационной системы будет осуществляться в CMS-
системе WordPress, которая является бесплатным инструментом, поддержива-
ющим выбранные технологии разработки приложения.
Проектируемая система должна функционировать в среде операционной
системы Windows 10, поскольку эта операционная система используется для
работы сотрудников организации.
1.4.3. Обоснование проектных решений по техническому обеспечению
Рассмотрим характеристики серверного оборудования, которыми оно
должно обладать для обеспечения надежной и бесперебойной работы. Сервер
должен обеспечить производительность системы и надежность хранения дан-
ных. Характеристики сервера представлены в таблице 5.
39
Таблица 5
Характеристика компонентов сервера
Наименование
Спецификация
Процессор
Intel Xeon 3330
Материнская плата
SuperMicro X7SBi
Чипсет
Intel® 3200/ICH9R chipset
Оперативная п
а-
мять
Kingston 2x2GB DDR2
-
667 ECC
Жесткий
диск
Seagate Barracuda ES.2, 1000GB, SATA
-
2
Сетевые
карты
2x Intel 82573V Gigabit Ethernet 10/100/1000Mbps
Персональные компьютеры (ПК) пользователей должны иметь достаточ-
но ресурсов, чтобы обеспечивать доступ к разрабатываемым WEB-страницам.
Характеристики пользовательских ПК представлены в таблице 6.
Таблица 6
Характеристика пользовательских компьютеров
Наименование
Спецификация
Процессор
Intel Core i3
Частота процессора
4 ГГц
Оперативная память
4 ГБ RAM
Объем жесткого диска
500 ГБ HDD
Средства организации локально-вычислительной сети (ЛВС) компании, к
которым относятся маршрутизаторы, коммутаторы, сегменты ЛВС, коммута-
ционные розетки и т.д.
Рассмотрим критерии выбора каждого из компонентов технического
обеспечения. Поскольку на сервере хранится и обрабатывается вся информация
всех информационных систем, для этого вида оборудования характерна пред-
намеренная избыточность основных компонентов. Основным критерием при
выборе платформы сервера является специфика поставленных и количество ав-
томатизированных рабочих мест, которые объединяются в сеть. После этого
остается только выбрать производителя.
Основным критерием при выборе сервера СУБД является отказоустойчи-
вость и пропускная способность сетевого интерфейса. Поскольку разрабатыва-
емый программный продукт будет использоваться ежедневно в рабочее время и
работать с ним будут одновременно 10 сотрудников, то загруженность сетевой
инфраструктуры составит 30%. При этом загруженность сервера баз данных
будет составлять 25%. Отталкиваясь от расчетов, становится очевидным, что
40
необходимость в покупке высокопроизводительного сервера с сетевым адапте-
ром скоростью в 1Gbps отсутствует, достаточно ограничиться интерфейсом в
100Mbps.
В результате анализа критериев выбора серверного оборудования можно
с полной уверенностью полагать, что сервер, используемый в организации об-
ладает необходимой мощностью для того, чтобы обеспечить оперативное и от-
казоустойчивое функционирование проектируемой информационной системы.
В качестве сервера баз данных будет использован сервер, построенный на
платформе HP ProLiant DL365 G5, обладающий характеристиками, перечис-
ленными в таблице 7.
Таблица 7
Характеристика сервера баз данных
На
именование
Спецификация
Процессор
Двуядерный Intel® Xeon® X5260 с тактовой
частотой 3,3 Гц.
Количество процессоров
2
Оперативная память
16 Гб (расширяемая до 64Гб)
Жесткий
диск
Тип «SAS» 4 диска 147 Гб и 2 диска 73 Гб
Количество жестких дисков
6
(расширяемо до 8)
Питание
Дополнительно резервный блок питания 800Вт
с горячей заменой
Приведем обоснование выбора представленной платформы. Наличие двух
процессоров позволяет при использовании SQL-сервера осуществить эффек-
тивное распараллеливание задач, которые будут выполняться на сервере. Опе-
ративная память объемом 16 Гб будет достаточной для осуществления обра-
ботки больших объемов информации, используемых на данный момент в базе
данных, а также последующего увеличения вычислительной нагрузки, так как
на данный момент пиковый размер занятой оперативной памяти составляет 6
Гб.
Использование 6 жестких дисков применяется для отказоустойчивости
серверной операционной системы. Также был организован RAID массив из
двух жестких дисков каждый по 73 ГБ (такого объема достаточно для работы
ОС). Операционная система установлена на отдельный от файлов базы данных
жесткий диск для обеспечения безопасности и производительности.
41
Для того, чтобы обеспечить надежность хранения данных в формате
Structured Query Language (SQL) был организован массив жестких дисков
большего объема – 147 Гб. Жесткого диска такого объема достаточно для внед-
рения нового функционала, на данный момент объем занятого дискового про-
странства составляет 53 Гб, при условии, что в базе данных информация будет
храниться в течении 5 лет.
Так же отдельно необходимо хранить данные в формате MDF (файл базы
данных) и транзакции в формате LDF (файл транзакций), для чего необходим
еще один массив, аналогичный предыдущему по размеру.
Пользовательские ПК, существующие в организации, имеют достаточный
уровень производительности для функционирования разрабатываемой инфор-
мационной системы, в результате чего не подлежат модернизации.
42
2. ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Процесс разработки программного обеспечения (ПО) является достаточно
сложным. Поэтому существует несколько стандартов, которые содержат реко-
мендации относительно процесса разработки программного обеспечения. Со-
временные стандарты в области разработки программного обеспечения не
предписывают четких и однозначных схем построения структуры жизненного
цикла ПО. Международные стандарты регламентируют перечень видов дея-
тельности, из которых должен состоять процесс разработки, и вводят ту или
иную структуру жизненного цикла разработки ПО.
Существуют стандарты, определяющие различные элементы в структуре
жизненных циклов ПО. Основу таких элементов составляют технологические
процессы – структурированные наборы деятельностей, решающие некоторую
общую задачу или совокупность задач, такие, как процесс определения требо-
ваний, процесс разработки, процесс сопровождения ПО, процесс обеспечения
качества, процесс разработки документации, процесс тестирования и пр.
Рекомендуемый состав стадий жизненного цикла программного обеспе-
чения регламентируют стандарты ISO, которые описывают технологические
процессы.
Стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология.
Системная и программная инженерия. Процессы жизненного цикла программ-
ных средств» определяет общую структуру жизненного цикла ПО в виде трех-
уровневой модели, элементами которой являются процессы, виды деятельно-
сти, задачи [9]. Процессы объединены в четыре группы: основные процессы,
поддерживающие процессы, организационные процессы, адаптация. Процессы
состоят из отдельных видов деятельности.
Стандарт ISO/IEC 15288:2015 «Разработка систем и программного обес-
печения – Процессы жизненного цикла систем» рассматривает программно-
43
аппаратную систему как единое целое [6]. Стандарт предлагает рассматривать
структуру жизненного цикла ПО как набор групп процессов, каждый из кото-
рых описывается набором результатов, и каждый из результатов достигается
при помощи набора различных видов деятельности. Эффективность разработки
ПО в целом зависит от точности и корректности формулировки требований к
программному продукту.
Правила работы с требованиями к программному обеспечению рассмат-
риваются в стандарте IEEE 830-1998 «Recommended practice for software
requirements specifications» [2]. Стандарт регламентирует состав документации
для фиксирования требований к ПО, а также дает определение характеристи-
кам, которыми должен обладать правильно составленный набор требований.
ст для программно-аппаратных систем в целом, а также определяет необ-
ходимые свойства и атрибуты набора требований [4]. Согласно стандарту, про-
цесс разработки требований включает определение, организацию, представле-
ние и модификацию требований.
Один из важных этапов в разработке программного обеспечения – это
процесс проектирования архитектуры информационной системы (ИС). Архи-
тектура системы позволяет определить большинство характеристик автомати-
зированной информационной системы (АИС) и служит основным средством
общения между разработчиками и всеми остальными лицами, заинтересован-
ными в данном ПО.
Рассмотрим стандарты, которые регламентируют процесс проектирова-
ния архитектуры АИС. Стандарт IEEE 1016-1998 «Recommended Practice for
Software Design Descriptions» описывает принципы разработки непосредственно
архитектуры АИС, а не ее компонентов [3].
Стандарт ISO/IEC 42010 IEEE Std 1471-2011 «System and software engi-
neering – Recommended practice for architectural description of software-intensive
systems» представляет архитектуру системы в виде комплекса представлений,
которые отражают структуру ПО с разных точек зрения [5]. В соответствии со
стандартом каждое представление архитектуры должно учитывать отраженные
44
в нем взгляды и интересы, причины, обуславливающие необходимость такого
рассмотрения системы, несоответствия между элементами одного представле-
ния или между различными представлениями, а также различную служебную
информацию.
Стандарт ISO 9001:2015 «Quality management systems – Requirements»
определяет требования к качеству программного продукта, а также правила его
обеспечения [1]. Стандарт ISO/IEC 90003:2004 «Software engineering – Guide
lines for the application of ISO 9001:2000 to computer software» описывает поло-
жения по применению стандарта ISO 9001:2000 к программному обеспечению
[7]. Также этот стандарт помогает определить набор техник и процедур, кото-
рые будут применяться для осуществления контроля и обеспечения качества
разрабатываемых программ.
Отечественной разработкой стал стандарт ГОСТ 34.601-90. Один из
наиболее применяемых до сих пор стандартов, хоть и был разработан почти 30
лет назад. Распространяется на автоматизированные системы (АС), используе-
мые в различных видах деятельности (исследование, проектирование, управле-
ние и т.п.), включая их сочетания, создаваемые в организациях, объединениях и
на предприятиях. Процесс создания АС представляет собой совокупность упо-
рядоченных во времени, взаимосвязанных, объединённых в стадии и этапы ра-
бот, выполнение которых необходимо и достаточно для создания АС, соответ-
ствующей заданным требованиям. Стадии и этапы создания АС выделяются
как части процесса создания по соображениям рационального планирования и
организации работ, заканчивающихся заданным результатом. Работы по разви-
тию АС осуществляют по стадиям и этапам, применяемым для создания АС.
Состав и правила выполнения работ на установленных настоящим стандартом
стадиях и этапах определяют в соответствующей документации организаций,
участвующих в создании конкретных видов АС [8]. Преимуществом стандарта
является то, что он не требует знаний в области ИТ и, следовательно, понятен
обычным управленцам. Он компактен и прост по структуре, что позволяет че-
ловеку, не знакомому с ним, быстро освоить его, самодостаточен - практически
45
никаких ссылок на смежные документы в нем нет. И наконец, он практичен -
сразу понятно, как его применять и как контролировать его применение. Со-
гласно этому стандарту жизненный цикл процесса разработки АИС делится на
следующие этапы:
1. Формирование требований к АС.
2. Разработка концепции АС.
3. Техническое задание.
4. Эскизный проект.
5. Технический проект.
6. Рабочая документация.
7. Ввод в действие.
8. Сопровождение АС.
У этого стандарта есть один недостаток: в стандарте заложены устарев-
шие представления об архитектуре АИС. Примерами этого являются следую-
щие утверждения:
•
программные продукты двухуровневые, включающие клиентскую
программу и сервер СУБД.
•
описание структуры таблиц базы данных дает представление о логи-
ческой модели данных.
•
используется однооконный пользовательский интерфейс.
•
система содержит небольшое количество отчетов, они являются бу-
мажными и печатаются на принтере матричного типа.
•
АИС разрабатывается для решения задач обработки данных, которые
имеют четкий вход и выход и являются узкоспециализированными. Основу об-
работки информации составляет алгоритм.
Так же существуют следующие стандарты разработки АИС:
• «Custom Development Method» методика компании «Oracle», применя-
емая для разработки прикладных информационных систем [19, стр. 113]. Этот
метод является технологическим материалом, детализированным до уровня
шаблонов проектной документации, рассчитанной на применение в проектах