56
Основные характеристики All Fusion Process Modeler:
Поддержка методологии функционального моделирования на основе
IDEF0;
Редакторы для описания операций, связей и вычисления затрат на
выполнение работ;
Иерархическая структура диаграмм;
Контекстные диаграммы для описания границ системы, области
действия, назначения объектов;
Декомпозиционные диаграммы для описания особенностей
взаимодействия различных процессов;
Поддержание ссылочной целостности;
Поддержка методологии IDEF3;
Экспорт моделей в средства имитационного моделирования;
Интеграция и связь со средством проектирования баз данных Erwin
(методология IDEF1X);
Поддержка свойств, определяемых пользователем.
Интеграция с ModelMart. Сервер приложений для программных продуктов
CA ModelMart поддерживает набор инструментальных программных средств,
обеспечивающих совместное (групповое) проектирование и разработку
программных систем, включая механизмы объединения моделей и анализа
изменений, контроль версий, возможность создания «компонента» модели и т.д.
Удобный интерфейс пользователя. В распоряжении пользователей
имеется проводник, позволяющий переходить с одной диаграммы на другую
перемещением по «дереву» проводника.
Автоматическая поддержка изменения размеров. All Fusion Process
Modeler поддерживает автоматическую настройку размеров диаграмм и
возможность изменения масштабов изображения моделей.
Из рассмотренных выше в п. 1.3.1 языков программирования Perl и PHP
было выявлено, что наиболее подходящими для разработки web приложений он-
лайн продаж является PHP, т.к.:
PHP быстрее обрабатывает пользовательские запросы , следовательно
способен обработать большее число клиентов, чем Perl;
57
PHP обладает наиболее обширным количеством функций для
реализации проекта;
За счет интеграции интерпретатора в web сервер значительно
повышается производительность АС;
Легкость отладки АС на этапе проектирования за счет отображения
конкретных ошибок в коде;
Широкий набор встроенных функций для работы по протоколу HTTP,
не требующих подключения дополнительных модулей;
Наличие русифицированной документации.
В роли СУБД выбран MY SQL SERVER [2, 7], т.к.:
Поддержка больших БД и параллельность обработки данных;
Импорт/экспорт информации из других СУБД;
Не предназначен непосредственно для разработки пользовательских
приложений, а выполняет функции управления базой данных.
Разработка пользовательского приложения для данной АС выполняется
при помощи PHP и HTML. [4, 17]
Архитектура Dynamic Locking позволяет достичь максимальной
производительности и подключения большего числа пользователей
Из существующих аналогов, рассмотренных выше в п. 1.3.1 Joomla, Drupal
и Wordpress,- программы позволяющие создавать системы электронных продаж,
было выявлено, что каждая из них имеет свои преимущества и недостатки в
описываемыми ими функциями.
Система Joomla в основном рассчитана для разработки небольших систем,
имеющих небольшой объем данных. Если объем данных значителен, то
существенно замедляется скорость генерации страниц. Каждая из этих систем
имеет большой выбор готовых шаблонов для организации пользовательского
интерфейса. Но большинство из них имеют стандартный вид с изменением
цветовой гаммы и расположением различных модулей. А при использовании
нестандартного шаблона интерфейса возникают проблемы и большие
трудозатраты для наложения его на эти системы, необходимость подключения
большого числа дополнительных модулей, что замедляет работу системы. Так
же одним из важнейших требований является удобство администрирования
58
системы – добавление и изменение разделов, изменение, удаление и добавление
информации о товаре. В системе Drupal плохо развита организация добавления
изображений. В стандартном пакете она не предусмотрена. Необходимо
устанавливать дополнительные модули.
Русской документации для этих систем не существует. Решение какого
либо вопроса необходимо искать на различных неофициальных сайтах.
Итог: Эти системы являются хорошим средством для быстрого создания
небольших продуктов. Но для создания более крупного продукта необходимо
подключать большое число модулей, что будет замедлять работу
разрабатываемой АС. Эти системы в основном рассчитаны на создание
продукта с типовым, шаблонным интерфейсом. Также в них реализовано много
функций, таких как форум, гостевая книга и т.д., которые не нужны для
разрабатываемой АС. Разрабатываемая система будет использоваться для
выполнения конкретной задачи, а следовательно в нее будет включен набор
только необходимых функций, не замедляющих работу системы. Так же для
разрабатываемой системы будет создан четкий, удобный и оригинальный
интерфейс, не требующий подключения каких либо дополнительных модулей.
1.4.3. Обоснование проектных решений по техническому
обеспечению.
Техническое обеспечение - комплекс технических средств,
предназначенных для работы информационной системы, а также
соответствующая документация на эти средства и технологические процессы.
Комплекс технических средств составляют:
компьютеры;
устройства сбора, накопления, обработки, передачи и вывода
информации - жесткие диски, устройства хранения данных, сканеры,
принтеры, факсимильные аппараты;
устройства передачи данных и линий связи - модемы;
эксплуатационные материалы - CD (DVD) - диски и т.п.
59
В нашем случае основными элементами технического обеспечения будут
автоматизированные рабочие места персонала организации.
Администрированием и разработкой интернет-магазина будут заниматься
сотрудники технического отдела «Литера». Для работы сотрудникам подойдут
имеющиеся на предприятие компьютеры. Взаимодействие с интернет-магазином
происходит посредством любого веб-браузера, выпущенного не раньше 2010
года. Пример конфигурации стандартного персонального компьютера в
«Литера» приведен ниже:
системная плата – ASRock H81M-DGS R2.0;
процессор - Intel Core i3-4330 3.50 GHz (4CPUs);
оперативная память – 4 GB DDR3 1333 MHz;
жесткий диск - 450 GB Serial ATA;
видеокарта - Intel HD Graphics 4600 1760 MB;
сеть – Realtek PCIe GBE Family Controller 10/100/1000 MB/sec;
питание - 400W.
60
II. ПРОЕКТНАЯ ЧАСТЬ.
2.1. Разработка проекта автоматизации.
2.1.1. Этапы жизненного цикла проекта интернет-магазина.
Жизненный цикл программного обеспечения — период времени, который
начинается с момента принятия решения о необходимости создания
программного продукта и заканчивается в момент его полного изъятия из
эксплуатации.
Важно еще при создании сайта понимать, что с запуском сайта в
эксплуатацию работа над ним не заканчивается. Предстоит еще многое сделать,
а возможно и переделать. Наличие таких составляющих как: масштабируемая и
гибкая логическая структура, продуманность потоков данных и программного
дизайна, разделение содержания, оформления и программных модулей – даже не
дает конкурентного преимущества, а просто дает интернет-магазину шанс на
существование.
Что может произойти с магазином, который сделали раз и навсегда?
Бывает, что магазин пускается в эксплуатацию, оценивается его эффективность
и принимается решение о дальнейшей работе. Варианты тестирования и отладки
в процессе работы не рассматриваются.
Более удачный вариант. Например, выясняется, что процесс заполнения
корзины и отправки заказа не слишком удобен или сопровождается
программными сбоями. Встает задача изменения определенных элементов
визуального дизайна с соответствующими изменениями в программных
модулях. Если возможность значительных изменений не была заложена
изначально, возникнут проблемы - потребуется в худшем случае изменить
значительную часть графического дизайна и/или переработать значительную
часть программного кода. Трудоемкость и соответственно стоимость таких
изменений может достигать до 50% первоначальной стоимости проекта и выше.
В связи с возможными изменениями требований к проектируемой системе
в процессе ее разработки, минимизации рисков несоответствия качеству и
других рисков, предполагается разработка интернет-магазина по стандарту
жизненных циклов RUP.
Rational Unified Process (RUP) [9] — методология разработки
61
программного обеспечения, созданная компанией Rational Software.
Прецедент (вариант использования, сценарий использования) —
спецификация последовательностей действий (варианты последовательностей и
ошибочные последовательности), которые может осуществлять система,
подсистема или класс, взаимодействуя с внешними участниками.
В основе RUP лежат следующие принципы:
ранняя идентификация и непрерывное (до окончания проекта)
устранение основных рисков;
концентрация на выполнение требований заказчиков к исполняемой
программе (анализ и построение модели прецедентов (вариантов
использования));
ожидание изменений в требованиях, проектных решениях и
реализации в процессе разработки;
компонентная архитектура, реализуемая и тестируемая на ранних
стадиях проекта;
постоянное обеспечение качества на всех этапах разработки
проекта.
RUP использует итеративную модель разработки. В конце каждой
итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда
должна достичь запланированных на данную итерацию целей, создать или
доработать проектные артефакты и получить промежуточную, но
функциональную версию конечного продукта. Итеративная разработка
позволяет быстро реагировать на меняющиеся требования, обнаруживать и
устранять риски на ранних стадиях проекта, а также эффективно контролировать
качество создаваемого продукта.
Итерационный подход к разработке позволяет создавать функционал
конечного продукта в виде небольших приращений. При этом наиболее
приоритетные части, которые могут принести наиболее быструю бизнес отдачу,
реализуются в первую очередь. Параллельно при этом необходимо
взаимодействовать с заинтересованными лицами, учитывать все их замечания и
предложения и вносить оперативные коррективы в ход проекта. Это дает
возможность еще на ранних стадиях значительно уменьшить риски и
62
динамически корректировать процесс, непрерывно направляя его в самое
эффективное русло.
Полный жизненный цикл разработки состоит из четырех фаз, каждая из
которых включает в себя одну или несколько итераций:
начало;
проектирование;
построение;
внедрение.
1) Начало.
Формируются видение и границы проекта – создание
интернет-магазина.
Создается технико-экономическое обоснование необходимости
разработки.
Определяются основные требования, ограничения и ключевая
функциональность разработки.
Создается базовая версия модели прецедентов.
Оцениваются риски.
При завершении начальной стадии оценивается достижение вехи целей
жизненного цикла, которое предполагает соглашение коммерческого директора
и уполномоченных сотрудников технического отдела о продолжении проекта.
2) Проектирование.
На этапе проектирования коммерческий директор постоянно
взаимодействует с уполномоченными сотрудниками технического отдела,
производится анализ предметной области и построение исполняемой
архитектуры. Это включает в себя:
Разработку технического задания (включая детальное описание для
большинства прецедентов).
Спроектированную, реализованную и оттестированную исполняемую
архитектуру (схемы прецедентов, ролей и функций объектов системы
(модулей, плагинов, расширений)).
Обновленное экономическое обоснование и более точные оценки
сроков и стоимости доработки решения.
63
Сниженные основные риски.
Успешное выполнение фазы проектирования означает достижение вехи
архитектуры жизненного цикла.
3) Построение.
Во время этой фазы происходит реализация большей части
функциональности продукта. Происходит разработка макета профессиональным
дизайнером, его верстка участником проекта, доработка, поиск необходимых
расширений, компонентов и плагинов, либо их собственная разработка. Фаза
«Построение» завершается первым релизом интернет-магазина и вехой
начальной функциональной готовности.
4) Внедрение.
Во время фазы «Внедрение» создается финальная версия продукта.
Проводится бета-тестирование, обучение пользователей, а также определение
качества продукта. В случае если качество не соответствует ожиданиям
пользователей, или критериям, установленным в фазе «Начало», фаза
«Внедрение» повторяется снова. В случае удовлетворительного качества
разработки интернет-магазин переносится с локального компьютера на хостинг.
После переноса магазина на хостинг, проводится заключительное бета-
тестирование. Выполнение всех целей означает достижение вехи готового
продукта и завершение полного цикла разработки.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их
описание.
На каждом из этапов разработки возможны риски, многие из которых
минимизируются за счет итерационного метода разработки. Ниже приведены
основные риски по этапам.
Этап «Начало».
Риск неоднозначной или неполной постановки требований, ограничений и
ключевой функциональности разработки. Может полностью загубить проект,
дав неверное направление разработке с самого начала. Для минимизации
данного риска с командой разработчиков должен тесно взаимодействовать
квалифицированный, заинтересованный в разработке представитель заказчика
64
(коммерческий директор). Команда разработчиков должна высказать свое
видение развития проекта и предложения. В конце данного этапа происходит
согласование полученных результатов, минимизирующее неоднозначность и
неполноту требований, ограничений и ключевой функциональности разработки.
Риск некачественного технико-экономического обоснования, неясность
срока разработки и затрат на нее. Технико-экономическое обоснование должен
составлять квалифицированный сотрудник, объективно оценивающий
возможности и силы команды разработчиков.
Этап «Проектирование».
Риск неполного документирования требований. Техническое задание
может содержать не все требования к разрабатываемой системе, поэтому
заниматься разработкой технического задания должен квалифицированный,
заинтересованный в разработке специалист (коммерческий директор). Так же
возможна помощь в формировании требований со стороны команды
разработчиков, как более опытной в данной области. Необходимо решить, как
интернет-магазин должен выглядеть в идеале, и найти компромиссное решение,
каким он может быть за имеющиеся средства.
Этап «Построение».
Риск недостаточного качества макета. Для минимизации риска
необходимо обратиться в профессиональную веб-студию, предоставляя
требования к дизайну из технического задания.
Риск приостановки проекта. Во время разработки проекта может
уволиться или быть недоступным ключевой участник команды разработчиков.
Для минимизации риска разработка проводится попарно – один участник
занимается кодом, его напарник параллельно просматривает его работу, потом
они меняются местами. Таким образом, все участники разработки максимально
ознакомлены с проектом, могут подменять друг друга и оперативно
обнаруживать и устранять ошибки. Так же необходимо максимально понятно
писать код и активно его комментировать.
Этап «Внедрение».
Риск несоответствия качества финальной версии разработки. Риск
минимизируется путем строгого выполнения всех требований, определенных в
65
задокументированных требованиях. Если качество не соответствует
требованиям, итерация разработки финальной версии повторяется.
Для снижения рисков проекта в целом необходимо предварительно
провести маркетинговые исследования. Рекомендуется выполнить следующие
работы:
Анализ идей сайтов-конкурентов. Необходимо понять, как и за счет
чего конкурент зарабатывает деньги с помощью сайта.
Анализ доменов. Основная цель веб-маркетинга при анализе доменов
конкурентов - срок регистрации домена и срок жизни сайта.
Анализ контента сайта конкурента. Определение объема и соотношения
текста, графики и таблиц сайтов конкурентов.
Определения качества контента сайтов конкурентов. От качества
контента сайта во многом зависит прибыль от сайта.
Оценка конкурентов. Оценка возможностей сайта конкурента, затрат на
его поддержку и раскрутку.
Оценка сильных и слабых сторон сайтов конкурентов.
2.1.3. Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации.
Организационно-правовые нормы обеспечения безопасности и защиты
информации на любом предприятии отражаются в совокупности учредительных
и организационных документов.
Огромное число успешных взломов наглядно показывает незащищенность
большинства веб-ресурсов. Потеря базы данных клиентов, паролей, почтовых
адресов, программного кода – все это может серьезно подорвать репутацию,
лояльность аудитории, а соответственно и доход фирмы. В связи с этим крайне
важно уделять внимание информационной безопасности и защите информации.
Ниже представлены основные средства обеспечения информационной
безопасности и защиты информации.
Защита от внутренних угроз.