Поскольку сотрудники организации обладают опытом разработки
программного обеспечения, подходящим вариантом разработки системы,
автоматизирующей предоставление рекламных услуг, является разработка системы
своими силами.
1.4. Обоснование проектных решений
1.4.1. Обоснование проектных решений по информационному
обеспечению
Входным документом рассматриваемой задачи является договор на
предоставление рекламных услуг и макет рекламы. Договор используется в
рассматриваемом процессе для контроля соответствия предоставляемых услуг его
условиям. Для автоматизации процесса этот документ не будет использован,
поэтому не требуется проектирование его формы.
Макет рекламы будет использован, в нем содержится следующая
информация:
• Текст рекламного объявления;
• Баннер (не обязательное условия);
• Набор ключевых слов.
Макет рекламного объявления не имеет унифицированной формы, поэтому
при разработке системы потребуется оригинальное проектирование формы
приложения. К оперативной информации рассматриваемой задаче относится
размещение рекламного объявления. В этом случае макет объявления размещается
на одной или нескольких площадках, задается срок размещения и вводятся
ключевые слова для поиска.
Размещение не имеет унифицированной формы, поэтому потребуется
оригинальное проектирование формы приложения.
Рассмотрим справочную информацию, которая должна быть в системе:
1. База клиентов, в которой перечислены все клиенты организации.
2. База площадок, на которых возможно разместить рекламу.
3. Перечень сотрудников отдела маркетинга.
4. Перечень статистических показателей для каждого объявления. Для
ввода, редактирования, просмотра и удаления справочной информации также
требуется проектирование оригинальных форм приложения.
К выходной информации проектируемой системы относятся сбор
статистики:
1. Количество переходов по ссылке.
2. Количество покупок после перехода.
3. Количество показов рекламы.
Перечисленные статистические показатели должны быть представлены в
табличной форме. Унифицированная форма таких отчетов также отсутствует,
поэтому потребуется проектирование оригинальной формы вывода результатной
информации
1.4.2. Обоснование проектных решений по программному
обеспечению
Поскольку организация осуществляет рекламную деятельность в сети
интернет с помощью размещения контекстной рекламы и баннеров. Для
управления рекламной деятельностью будет использована web-ориентированная
информационная система: она будет представлять собой web-страницы и
программный код для их обработки. Поэтому для создания системы будут
использованы следующие технологии [16]:
• HTML5 – для создания и разметки страницы;
• PHP7 – для программной обработки данных на web-страницах;
• CSS4 – для оформления и верстки объектов на web-странице.
Разработка web-страниц будет осуществляться с помощью CMS-системы
«Joomla», которая является бесплатной CMS-системой с множеством шаблонов для
создания web-ресурса. Для создания страниц в CMS-системе «Joomla» необходима
установка webсервера. Для рассматриваемой задачи в качестве web-сервера был
выбран webсервер Apache, который входит в пакет Denwer. Для разработки базы
данных будет использована СУБД MySQL, которая является реляционной базой
данных.
Использование реляционной базы данных позволит:
• Обеспечить простоту представления данных благодаря тому, что в
реляционной модели данных существует всего одна информационная конструкция,
формализующая табличное представление данных.
• С помощью теоретически обоснованных методов нормализации
отношений получение базы данных с заданными характеристиками.
• Обеспечить независимость данных заключается в том, что при
необходимости внесения изменений в структуру реляционной базы данных,
требуется внесение минимальных изменений [12].
Разрабатываемая система должна корректно отображаться во всех
браузерах и быть кросс-плаформенной.
На сервере, на котором будет размещена серверная часть системы, будет
установлена операционная система Windows Server 2012. На клиентских ПК будет
установлена операционная система Windows 10.
1.4.3. Обоснование проектных решений по техническому
обеспечению
Рассмотрим критерии выбора технического обеспечения для поставленной
задачи. Поскольку на сервере хранится и обрабатывается вся информация
информационных систем, для этого вида оборудования характерна преднамеренная
избыточность основных компонентов. Основным критерием при выборе
платформы сервера является специфика поставленных и количество
автоматизированных рабочих мест, которые объединяются в сеть [3].
После этого остается только выбрать производителя. Основным критерием
при выборе сервера СУБД является отказоустойчивость и пропускная способность
сетевого интерфейса [21].
Поскольку разрабатываемый программный продукт будет использоваться
ежедневно в рабочее время, а работать с ней будут 10 сотрудников, загруженность
сетевой инфраструктуры будет равна 30%. При этом загруженность сервера баз
данных будет составлять 25%. Поэтому отсутствует необходимость в покупке
высокопроизводительного сервер с сетевым адаптером скоростью в 1Gbps,
достаточно ограничиться интерфейсом в 100Mbps.
В результате анализа критериев выбора серверного оборудования можно
заключиться, что сервер, используемый в организации, обладает необходимой
мощностью для того, чтобы обеспечить оперативное и отказоустойчивое
функционирование проектируемой информационной системы. В качестве сервера
баз данных будет использован сервер, построенный на платформе HP ProLiant
DL365 G5, обладающий характеристиками, перечисленными в таблице 5.
Таблица 5
Характеристика сервера баз данных
Показатель
Спецификация
Процессор
Двуядерный Intel® Xeon® X5260 с тактовой
частотой 3,3 Гц.
Количество
процессоров
2
Оперативная память
16 Гб (расширяемая до 64Гб)
Жесткий диск
Тип «SAS» 4 диска 147 Гб и 2 диска 73 Гб
Количество жестких
дисков
6 (расширяемо до 8)
Питание
Дополнительно резервный блок питания 800Вт
с горячей заменой
Приведем обоснование выбора представленной платформы Использование
двух процессоров позволят при использовании SQL-сервера осуществить
эффективное распараллеливание задач, которые будут выполняться на сервере.
Оперативная память объемом 16 Гб будет достаточной для осуществления
обработки больших объемов информации, используемых на данный момент в базе
данных, а также последующего увеличения вычислительной нагрузки, так как на
данный момент пиковый размер занятой оперативной памяти составляет 6 Гб.
Использование 6 жестких дисков применяется для обеспечения надежности
функционирования серверной операционной системы.
Операционная система установлена на отдельный от файлов базы данных
жесткий диск для обеспечения безопасности и производительности [24].
Для того, чтобы обеспечить надежность хранения данных в формате
Structured Query Language (SQL) был организован массив жестких дисков большего
объема – 1 Тб.
Жесткого диска такого объема достаточно для внедрения нового
функционала, на данный момент объем занятого пространства занимает 53Гб, при
условии того что в базе данных информация будет храниться в течении 5 лет.
Так же отдельно необходимо хранить данный в форматах mdf (файл базы
данных), а также транзакции в виде файлов ldf (файл транзакций), для чего
необходим еще один массив, аналогичный предыдущему по размеру.
Пользовательские ПК, используемые в организации, имеют достаточный уровень
производительности для функционирования разрабатываемой информационной
системы, в связи с чем не подлежат модернизации.
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Существуют несколько стандартов, регламентирующих процесс разработки
программного обеспечения:
1. ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на
автоматизированные системы. Автоматизированные системы. Стадии создания».
2. ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология.
Системная и программная инженерия. Процессы жизненного цикла программных
средств».
Эти стандарты не предлагают конкретную модель жизненного цикла
программного обеспечения и методы его разработки. Стандарт ГОСТ Р ИСО/МЭК
12207-2010 «Информационная технология. Системная и программная инженерия.
Процессы жизненного цикла программных средств» содержит общие регламенты,
применяемые к любой модели жизненного цикла, методологии и технологий
разработки [2].
Стандарт ГОСТ 34.601-90 описывает структуру процессов жизненного
цикла, но не конкретизирует в деталях, как реализовать или выполнить действия и
задачи, включенные в эти процессы [1].
Рассмотрим существующие модели жизненного цикла программных
продуктов для того, чтобы выбрать наиболее подходящий проектируемой системе.
Когда программные продукты только начали разрабатываться, они имели
однородную структуру и каждое приложение являлось единым целым. Поэтому
для разработки программных продуктов такого типа применялась каскадная
модель жизненного цикла программного обеспечения. Основной характеристикой
этой модели является деление всего процесса разработки программного
обеспечения на ряд этапов.
При этом переходы между этапами осуществлялись только после полного
завершения работ на текущем этапе. Каждый этап каскадной модели завершался
выпуском полного пакета проектной документации, которой достаточно для
продолжения процесса разработки другой командой разработчиков. Структура
каскадной модели представлена на рисунке 8.
Рисунок 8 – Структура каскадной модели жизненного цикла
программного обеспечения [19]
На схеме этапов каскадной модели жизненного цикла программного
обеспечения видно, что процесс разработки осуществляется при помощи
упорядоченной последовательности шагов. Каскадная модель предусматривает
начало каждой фазы только тогда, когда полностью завершается выполнение
предыдущей фазы. При этом у каждой фазы есть определенные критерии входа и
выхода: входные и выходные данные. Требования к проектируемой АИС
определяются на стадии анализа и затем документируются в техническом задании,
которое является опорным документом при создании АИС.
Каждая стадия каскадной модели должна завершаться выпуском полного
комплекта проектной документации, которая включает в себя:
1. Техническое задание;
2. Эскизный проект;
3. Технический проект;
4. Рабочую программу.
Перечисленный пакет документов является достаточным для продолжения
процесса разработки другой командой разработчиков. Критерий качества при
использовании каскадной модели жизненного цикла программного обеспечения –
точное соответствие спецификациям технического задания на разработку АИС.
При этом особое внимание разработчики уделяют достижению
оптимального значения технических характеристик разрабатываемой АИС:
производительности, объема занимаемой памяти и т.д.
С ростом объема коммерческих проектов разработки программных
продуктов было установлено, что детальная проработка проекта разрабатываемой
системы не всегда удается на этапе анализа, потому что многие аспекты
функционирования АИС в динамических сферах деятельности меняются во время
создания информационной системы. Это послужило созданию итерационной
модели жизненного цикла программного продукта. Итерационную модель также
называют моделью с промежуточным контролем или моделью с циклическим
повторением фаз.
Структура итерационной модели представлена на рисунке 9.
Рисунок 9 – Итерационная модель жизненного цикла
программного обеспечения [18]
При использовании итерационной модели жизненного цикла разработки
программного обеспечения существует возможность устранения недостатков
проектирования и программирования на более поздних стадиях при частичном
возврате на предыдущие стадии. При этом чем позже будет выявлена ошибка, тем
дороже ее исправление.
Если стоимость усилий, необходимых для обнаружения и устранения
ошибок на стадии написания кода, принять за единицу, то стоимость выявления и
устранения ошибки на стадии выработки требований будет в 5-10 раз меньше, а
стоимость выявления и устранения ошибки на стадии сопровождения – в 20 раз
больше.
Спиральная модель жизненного цикла программного продукта состоит из
четырех этапов, которые представлены четырьмя квадрантами спирали:
1. На этапе планирования осуществляется определение целей, вариантов и
ограничений проекта.
2. На этапе анализа риска осуществляется анализ вариантов и
распознавание/выбор риска проекта.
3. На этапе конструирования осуществляется разработка программного
продукта следующего уровня.
4. На этапе оценивания происходит оценка текущих результатов разработки
заказчиком. Структура спиральной модели представлена на рисунке 10.
Рисунок 10 – Схема спиральной модели жизненного цикла
разработки ПО [13]
Из рассматриваемых моделей жизненного цикла программных систем
наиболее подходящей моделью для проектируемой системы является спиральная
модель жизненного цикла, поскольку она обладает рядом достоинств по сравнению
с другими моделями:
1. Заказчик может оценить системные требования в процессе их сбора
командой разработчиков, поэтому взаимодействие заказчика с АИС начинается на
ранних этапах разработки.
2. Оценивая реакцию заказчиков при демонстрации разрабатываемого
продукта, разработчики получают сведения об одном или нескольких аспектах
поведения системы, благодаря чему сводится к минимуму количество неточностей
в требованиях.
3. Снижение возможности возникновения ошибок или искажений
информации при разработке системных требований, что приводит к созданию
более качественного конечного продукта.
4. Возможность внесения в процесс разработки новых или неожиданных
требований пользователей, что является необходимым, поскольку реальное
положение дел может отличаться концептуальной модели предметной области.
5. Модель позволяет выполнить гибкое проектирование и разработку,
включая несколько итераций на всех фазах жизненного цикла.
После того как был сделан выбор стандарта разработки программного
продукта и модели жизненного цикла, необходимо осуществить выбор стратегии
внедрения. Выделяют 4 стратегии внедрения программного обеспечения:
«Параллельная стратегия» - когда одновременно работают старая (ручная)
и новая система, и их выходные документы сравниваются. Если они согласуются
длительное время, осуществляется переход на новую систему.
«Скачок». Эта стратегия представляет собой резкий переход от
использования старой информационной системы к новой без каких-либо
дополнительных проверок и с полным отказом от старой системы.
«Пилотный проект». Это наиболее часто используемая стратегия.
«Пилотный проект» - это тактика «скачка», но применяемая к ограниченному
числу процессов. Область применения стратегии - небольшой участок
деятельности. Такой подход снижает риск и наиболее надежен. Практически все
предприятия применяют эту тактику сегодня.
«Узкое место». «Узкое место» - это малая часть производственного
процесса. При использовании похода «узкое место» план внедрения выполняется
только для «узкого места» и для людей, работающих в нем. Точность данных
повышается только для изделий в этом «узком месте»; переподготовка - только для
людей, работающих в нем; анализ эффект-затрат делается только для него и т.д.
Таким образом разработка программного обеспечения будет
осуществляться согласно стандарту ГОСТ Р ИСО/МЭК 12207-2010
«Информационная технология. Системная и программная инженерия. Процессы
жизненного цикла программных средств» и спиральной модели жизненного цикла.
Стратегией внедрения была выбрана «пилотный проект».
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
В процессе планирования проекта по разработке системы необходимо
проанализировать риски и разработать план реагирования на риски. Выявим риски,
которые могут быть выявлены на этапах жизненного цикла системы.
Рисками этапа разработки стратегии автоматизации являются [20]:
• недостаточное определение свойств проектируемой системы,
которые требуются для решения задачи;
• неверный выбор процессов автоматизации.
Последствиями этих рисков может стать необходимость доработки
системы, выявленная на этапе опытной эксплуатации, что повлечет за собой
дополнительные финансовые затраты. Предотвратить перечисленные риски
возможно с помощью применения CASE-средств при моделировании бизнес-
процессов на этапе выявления требований пользователей. Основным риском этапа
анализа предметной области является неправильное определение функций
системы.
Вследствие этого может возникнуть риск неправильного выбора способа
приобретения системы. Предотвращение риска возможно с помощью проведения
тщательного анализа всех способов приобретения системы.
Если риск все-таки осуществился, необходимо провести повторный анализ
вариантов выбора системы. Предыдущий риск взаимосвязан с риском
неправильного определения функций системы и стратегии автоматизации [23].
Устранение этого риска возможно с помощью применения CASE-средств в
процессе анализа предметной области. Рассмотрим риски этапа проектирования
системы. Одним из рисков этого этапа является разработка неэффективного плана-
графика проекта, которое заключается в использовании лишних ресурсов или в
дефиците ресурсов. Этот риск является финансовым, его устранение возможно с