68
В качестве HDD для серверов БД лучше применять диски SAS (Serial
Attached SCSI) на 10000 об/мин или 15000 об/мин. Такие диски оптимизированы
для работы на транзакционных нагрузках и по такому параметру имеют почти
трехкратную производительность, по сравнению с дисками SATA. Также диски
SAS изначально создавались под использование в RAID-массивах и показывают
почти всегда линейный рост скорости работы массива при увеличении числа
дисков в нем.
Современные процессоры значительнее производительнее, чем
процессоры 3-4 летней давности благодаря применению технологии
многоядерности. Сейчас сервер с 8-ю ядрами может приобрести почти каждая
организация.
Для "тяжелых" систем вскоре также отпадет необходимость установки
дорогостоящих многопроцессорных RISC-систем, которые при идентичной
производительности на порядок дороже. Сегодня существуют четырех- и
восьмипроцессорные серверы с архитектурой x86 и поддержкой четырех- и даже
шестиядерных процессоров, дает возможность иметь в одной системе до 32-х
ядер.
Итак, основные требования к серверу следующие:
двухъядерный процессор Intel;
объем оперативной памяти не менее 4 Гб;
контроллер RAID 1;
жёстких диска SAS не менее 750 Гб;
наличие привода DVD-RW;
сервер должен быть из линейки серверов Hewlett Packard.
Для сети рассматриваемой компании нужен недорогой, но надежный
сервер. Выбор предлагается произвести из серверов средней ценовой категории.
Сравнение серверов приведено в таблице 1.10.
Как видно из таблицы 1.10, при одинаковой конфигурации серверы имеют
ощутимое различие в стоимости. Сервер HP ProLiant DL180 gen9 имеет более
компактный размер, большую возможность для расширения, большую
отказоустойчивость. Однако, для рассматриваемой задачи эти характеристики не
69
являются критически важными, поэтому можно выбрать более дешевый вариант
с той же производительностью. Выбираем сервер HP ProLiant DL180 gen9.
Таблица 1.11
Сравнение серверов
Параметр
HP ProLiant DL180 gen9
HP ProLiant DL360 Gen9
Производитель
Intel
Intel
Тип
Xeon
Xeon
Код процессора
E5-2620 v4
E5-2620 v4
Частота
3.0 ГГц
3.0
Количество
процессоров
1
1
Кеш L3
20 Мб
20 Мб
Количество ядер
процессора
8
8
Оперативная память
Тип памяти
DDR4 ECC
DDR4
Объем памяти
16 Гб
16 Гб
Максимальный
объем памяти
128 Гб
256 Гб
Количество слотов
памяти
4
8
Стоимость
144990 рублей
171990 рублей
70
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл программных средств (ПС) в стандартах представляет
собой набор этапов, частных работ и операций в последовательности их
выполнения и взаимосвязях, регламентирующих ведение работ от подготовки
технического задания до завершения испытаний ряда версий и окончания
эксплуатации ПС или ИС. Стандарты включают правила описания исходной
информации, способов и методов выполнения операций, устанавливают
контроль технологических процессов, требования к оформлению их результатов.
А также регламентируют содержание технологических и эксплуатационных
документов на комплексы программ. Они определяют организационную
структуру коллектива, обеспечивают распределение и планирование заданий, а
также контроль над этапами создания комплекса ПС.
Для описания жизненных циклов (ЖЦ) ИС был выбран стандарт ISO
12207, как стандарт, охватывающий большинство автоматизированных систем
(АС) и ПС, где ПС – лишь часть всего плана работ. Международный стандарт
ISO/IEC 12207 определяет стратегию и общий порядок в создании и
эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до
завершения цикла. Определение стандарта: система — это объединение одного
или более процессов, аппаратных средств, программного обеспечения,
оборудования и людей для обеспечения возможности удовлетворения
определенных потребностей или целей.
В отличие от Oracle CDM стандарт ISO 12207 равносильно ориентирован
на организацию действий каждой из двух сторон: поставщик (разработчик) и
покупатель (пользователь). Может быть в равной степени применен, когда обе
стороны из одной организации. По сравнению с CDM стандарт ISO состоит из
гораздо более крупных обобщенных процессов: «приобретение», «поставка»,
«разработка» и т.п. Каждый процесс разделен на набор действий, любое
действие — на комплекс задач. Очень важное отличие ISO: любой процесс,
действие или задача инициируется и выполняется другим процессом по мере
71
необходимости, причем нет заранее определенных последовательностей
(естественно, при сохранении логики связей по исходным сведениям задач и
т.п.).
Динамический характер стандарта зависит от способа определения
последовательности выполнения процессов и задач, при котором один процесс
при необходимости вызывает другой или его часть. Стандарт определяет
архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также перечень
базовых работ и детализирует содержание каждой из них. Архитектура ЖЦ ПС в
стандарте базируется на трех крупных компонентах:
- Приобретение-заказ и поставка,
- Разработка,
- Эксплуатация.
Стандарт принципиально не содержит конкретные методы действий, тем
более — заготовки решений или документации. Он описывает архитектуру
процессов жизненного цикла ПО, но не конкретизирует в деталях, как
реализовать или выполнить услуги и задачи, включенные в процессы. Стандарт
не предписывает конкретную модель ЖЦ или метод разработки ПО, но
определяет, что стороны участники использования стандарта ответственны за
выбор модели ЖЦ для проекта ПО, за адаптацию процессов и задач стандарта к
этой модели, за выбор и применение методов разработки ПО, за выполнение
действий и задач, подходящих для проекта ПО.
На предпроектной стадии необходимо провести системный анализ. Он
включает в себя анализ функционирования и выявление недостатков
существующей технологии. На основе выявленных недостатков формулируется
потребность в совершенствовании системы, создается технико-экономическое
обоснование проекта (ТЭО), формулируются технические условия и требования
к ИС. Результаты должны быть оформлены в виде ТЗ (технического задания).
Первый этап выполняется бизнес-аналитиком отдела, с привлечением
сотрудников. Входную информацию бизнес-аналитик получает из интервью с
сотрудниками, характеризующих существующие бизнес-процессы.
1. Предпроектное рассмотрение. В ходе этого рассмотрения находятся
основные информационные потоки в компании и проверяется база основной
72
нормативно—справочной документации. Базовыми требованием в таком случае
становятся наличие всех нужных для работы корпоративных ИС справочников и
классификаторов, а также соответствие принципов их реализации с
требованиями системы. В процессе исполнения этапа важно проанализировать
на полноту все корпоративные стандарты учета и отчетности. Этот этап
включает также проведение диагностирования проблем, которые могут иметь
место при внедрении, а также согласовывается и выполняется настройка
справочников и классификаторов системы в строгом соответствии с указанными
требованиями. В случае необходимости принимается решение о перемене
внедренных практик учета или функциональных моделей. По итогам этапа
составляется подписываемый всеми участниками проекта внедрения документ,
описывающий все установленные недостатки и намечает пути их решения.
2. Реализация информационно-функциональной модели работы
предприятия, оптимизация и описание процессов, которые подлежат
автоматизации. Моделирование должно осуществляться хорошо обученными
сотрудниками исследуемой компании с привлечением опытных консультантов и
с привязкой построенной модели к стандартам бизнеса и к только что
спроектированной системе.
3. Адаптация ИС внутри компании. В ходе этапа реализуется настройка
системы тестирование ключевых модулей и функций группой внедрения. Этот
этап требует наличия корпоративных стандартов, так как именно они составляют
основу настроек системы.
4. Опытная эксплуатация ИС. Реализуется для тестирования четкого
соответствия функциональности, полученной в процессе отладки системы,
требованиям компании. На этом этапе присутствует двойной ввод данных в
новую и старую системы. В процессе опытной эксплуатации: создаются
стандартные отчеты (при помощи ИС и стандартными способами) и реализуется
проверка данных; система шаг за шагом вводится в эксплуатацию по каждому
участку учета; документируются инструкции по обслуживанию рабочих мест и
дополняются должностные инструкции всех членов учетного процесса. В
отдельных подразделениях компании в систему добавляются фактические
данные (в минимальном объеме) и последовательно проверяются бизнес—
73
функции при помощи моделирования реальных ситуаций работы компании (в
максимально приближенных к действительности условиях). Оттачивается
слаженная работа подразделений на базе тестовых пилотных примеров.
Конечные пользователи (сотрудники IT-отдела) проходят обучение с настроенной
системой только на своих рабочих местах. По завершению обучения конечных
пользователей реализуется встроенный пилотный пример и полностью
моделируется работа компании. Основываясь на результатах реализации
пилотного примера руководство компании принимает решение о переводе ИС в
повседневную эксплуатацию.
Следующий этап – проектирование ИС, включает в себя разработку в
соответствии со сформулированными требованиями состава автоматизируемых
функций (функциональная архитектура), состава обеспечивающих подсистем
(системная архитектура), оформление технического проекта ИС. Входной
информацией для проектирования является ТЗ. На этом этапе определяется
состав программных подсистем и компонентов оборудования, составляются
спецификации требований к компонентам ПО, определяется состав компонентов
ПО (в том числе повторно используемых компонентов), интерфейсы с БД,
структуры хранения данных, алгоритмы обработки информации, спецификации
интерфейсов с другими системами автоматизации, требования к тестам. Данный
этап является очень ответственным с точки зрения качества всей последующей
разработки.
На этапе реализации выполняется физическое проектирование,
программирование, наполнение баз данных, тестирование, разработка
инструкций для персонала.
Тестирование ИС. На этом этапе оценивается система в целом на
соответствие требованиям ТЗ.
Внедрение системы необходимо проводить в три этапа:
подготовка объекта к внедрению;
опытное внедрение;
сдача проекта в промышленную эксплуатацию.
На этапе подготовки объекта к внедрению планируется провести
следующие работы:
74
закупить и установить сервер системы и серверное ПО;
развернуть на сервере базу данных;
установить клиентское ПО на все компьютеры АРМ системы;
сконфигурировать взаимодействие АРМ системы с сервером базы
данных;
ввести учетные записи и настроить им права доступа;
заполнить справочники системы реальными данными;
обеспечить пользователей эксплуатационной документацией;
обучить персонал работе с системой.
В процессе внедрения системы участвуют: разработчики системы
(проектировщик, программист), системный администратор и будущие
пользователи системы. Системный администратор должен обеспечить место для
установки нового сервера; подключение к локальной сети для сервера и АРМ
пользователей системы; доступ к компьютерам, необходимым для развертывания
системы, с правами администратора. Проектировщик системы проводит
обучение пользователей, конфигурирует систему, заполняет справочники,
проверяет правильность взаимодействия всех подсистем. Программист
оперативно устраняет возникающие при развертывании системы неполадки.
Опытная эксплуатация системы должна проводиться не менее 3 месяцев.
В случае обнаружения ошибок на этапе опытной эксплуатации, осуществляется
поиск причин и устранение ошибок, внесение коррективов в программу, в
технологию обработки данных. После устранения ошибок подписывается «Акт о
проведении опытной эксплуатации», который служит началом перехода к
третьему этапу – сдаче системы в промышленную эксплуатацию.
На этапе эксплуатации производятся следующие работы:
- периодическая актуализация справочников системы (осуществляется
ответственным за справочник лицом);
- периодическое архивирование информационной базы системы на CD-
носителях (администратор системы);
- локализация проблем и устранение причин их возникновения
(программист);
- модификация ПО (бизнес-анатилик, программист);
75
- подготовка предложений по совершенствованию системы (пользователи
системы);
- развитие и модернизация системы (бизнес-анатилик, программист).
В связи с небольшим объемом проектных работ, а также характером
проекта выберем каскадную модель для описания жизненного цикла. В
соответствии с этим в него будут входить следующие этапы:
Формирование требований
Проектирование
Реализация
Тестирование
Ввод в действие
Эксплуатация и сопровождение
Так как выбрали использовать стандарт ISO/IEC 12207, то наиболее
подходящей к конкретной разработке является каскадная модель.
Каскадная модель обладает следующими преимуществами:
не требуется предварительного расхода средств, необходимых для
разработки всего проекта (поскольку сначала выполняется разработка и
реализация основной функции или функции из группы высокого риска);
в результате выполнения каждого из этапов получается
функциональный продукт;
заказчик располагает возможностью высказаться по поводу каждой
разработанной версии системы;
правило по принципу "разделяй и властвуй" позволяет разбить
возникшую проблему на управляемые части, благодаря чему предотвращается
формирование громоздких перечней требований, выдвигаемых перед командой
разработчиков;
существует возможность поддерживать постоянный прогресс в ходе
выполнения проекта.
В качестве стратегии внедрения ИС в ООО «Энергия уюта» был выбран
«Пилотный проект».
Пилотный проект – это первый этап внедрения, позволяющий убедиться в
применимости и эффективности предлагаемой системы до eё окончательного
76
внедрения, обучить сотрудников компании работе с системой, а также
определить и спланировать организационные и технические мероприятия на
этапе промышленного внедрения. Пилотный проект позволяет уменьшить
затраты и ускорить полномасштабное внедрение.
Данная стратегия внедрения информационной системы была выбрана,
потому что это наиболее часто используемая компаниями стратегия. Такой
подход снижает риск и наиболее надежен.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Данный раздел описывает риски, которые могут возникнуть на этапах ЖЦ
задачи учета продаж и поступлений для ООО «Энергия уюта». Риском является
возможность появления обстоятельств, обусловливающих неуверенность или
невозможность получения ожидаемых результатов от реализации поставленной
цели, нанесение материального ущерба, опасность валютных потерь и др.
Существуют следующие типы рисков:
Проектный тип рисков. В него включены риски, которые связаны с
ошибками в бюджете; в графике работ; с проблемами персонала организации;
риски различных изменений в текущем законодательстве.
Технический тип рисков. К нему относят риски, связанные с проблемами
реализации технических решений и человеческим фактором, а именно риски,
связанные с неспособностью специалистов выполнить необходимую задачу.
Тип бизнес-рисков. Он содержит в себе риски, которые связаны с
финансовой поддержкой задачи учета, или, другими словами, риски сокращения
бюджета, приводящие не только к сокращению проекта и его задач, но и к его
полному провалу в случае не достижения основной цели; риск потери интереса к
задаче ведения и учета внутренних заказов оборудования со стороны конечных
пользователей, риски при оценке рынка данного вида учета. Данный тип рисков
невозможно исключить, но его можно минимизировать.
Чтобы уменьшить величину данных типов рисков необходимо иметь
достаточно компетентных и квалифицированных сотрудников, имеющих
большой опыт работы в соответствующей области и при этом взаимозаменяемых
77
на сотрудников, не менее соответствующих данным характеристикам (таблица
2.1).
Таблица 2.1
Характеристики дефектов программного продукта
Этапы возникновения дефектов и ошибок
Типы первичных
дефектов и ошибок
программного средства
и документации
Формирование требований
Разработка требований к
ПО
Дефекты исходных
требований заказчика
Проектирование
Планирование работ
Дефекты,
обусловленные
реальной сложностью
проекта
Проектирование
архитектуры системы
Ошибки планирования
и системного
проектирования
программного средства
Детальное
проектирование ПО
Системные и
алгоритмические
дефекты и ошибки
проекта
Реализация
Кодирование ПО
Программные дефекты
и ошибки компонентов
и документов
программного средства
Тестирование
Тестирование ПО
Программные и
алгоритмические
ошибки программного
средства и
документации
Ввод в действие
Разработка документации
Дефекты и ошибки
обобщающих
документов
Эксплуатация и
сопровождение
Эксплуатация ПО
Программные дефекты.
На этапе эксплуатации возможны риски, возникающие по причинам:
1) Злоумышленных, активных воздействий заинтересованных лиц. Для
защиты от внешних угроз необходимо применять средства обеспечения защиты
программ и данных (аутентификация пользователей, защита локальной сети при
помощи межсетевых экранов, применение антивирусных программ и пр.).