57
2. Сформирована база данных на основе всех возможных данных от
разных складов, а именно разработана схема выгрузок, по которой информация
будет обновляться каждые 5-10 минут, о наличии товара, его изменении, и/или
еще какой-либо манипуляции. По данной схеме будет наполняться и
существовать каталог.
3.Обговорен дизайн, а именно наличие баннеров, новостей и акции, то
как они должны выглядеть и отображаться. Обговорен дизайн карточки товара,
как превью, так и полная страница, а именно указано что должно быть
показано, как для одного отображения, так и для второго.
4. Обговорен функционал всплывающих форм, а именно при каких
действиях они должны появляться и что должны оповещать, один из моментов
это в этих формах является система валидации полей, при не верном введении,
обработка формы не произойдет, а поле где данные были введены не верно,
подсветится красным.
5. Обговорен функционал корзины и оформления, а именно то что
должно отображаться, какие действия должны быть, и какие возможности есть
оформления. В это входит выбор возможности выбора системы доставки, типа
пользователя, системы оплаты. К этому всему сама разработка должна быть
такой, чтобы в будущем легко можно было добавить новые системы доставки и
оплаты. (распространённая практика для предусмотра расширения
функционала в будущем)
Исходя из того, что нам известны все данные, каждый шаг был описан в
ТЗ, и ТЗ является конечным продуктов разработки, была выбрана каскадная
модель жизненного цикла.
Жизненный цикл программного обеспечения, и все процессы разработки
регламентируются рядом стандартов, наиболее известные из которых мы
обсудим ниже. [10]
1. ГОСТ 34.601-90
Данный стандарт устанавливает общие основы для описания жизненного
цикла систем, созданных людьми, определяет детально структурированные
58
процессы и соответствующую терминологию. Определенные совокупности
этих процессов могут быть реализованы на любом иерархическом уровне
структуры системы. Выбранные из этих совокупностей процессы могут быть
использованы в течение всего жизненного цикла системы для реализации и
управления отдельными стадиями жизненного цикла, что осуществляется
путем вовлечения всех участников, заинтересованных в достижении конечной
цели - удовлетворенности заказчиков.
В этом стандарте представлены также процессы, которые поддерживают
определение, контроль и совершенствование процессов жизненного цикла
внутри организации или в рамках какого-либо проекта. Организации и проекты
могут применять эти процессы при приобретении и поставке систем.
Стандарт распространяется на системы, которые созданы человеком и
состоят из одного или нескольких следующих элементов: технические
средства, программные средства, люди, процессы (например, процесс оценки),
процедуры (например, инструкции оператора), основные средства и природные
ресурсы (например, вода, объекты живой природы, минералы).
2. ISO/IEC 12207:1995
Это стандарт на процессы и организацию жизненного цикла.
Распространяется на все виды заказного ПО. Стандарт не содержит описания
фаз, стадий этапов. [3]
3. Custom Development Method (и, методика Oracle)
Стандарт по разработке прикладных информационных систем под заказ -
конкретный материал, детализированный до уровня заготовок проектных
документов, рассчитанных на использование в проектах с применением Oracle.
Степень адаптивности CDM ограничивается тремя моделями ЖЦ:
"классическая" (предусмотрены все работы/задачи и этапы), "быстрая
разработка" (Fast Track), "облегченный подход", рекомендуемый в случае
малых проектов и возможности быстро прототипировать приложения.
4. Rational Unified Process (RUP)
59
Этот стандарт предлагает итеративную модель разработки, включающую
четыре фазы: начало, исследование, построение и внедрение. Каждая фаза
может быть разбита на этапы (итерации), в результате которых выпускается
версия для внутреннего или внешнего использования. Прохождение через
четыре основные фазы называется циклом разработки, каждый цикл
завершается генерацией версии системы. Если после этого работа над проектом
не прекращается, то полученный продукт продолжает развиваться и снова
минует те же фазы [3]. Суть работы в рамках RUP - это создание и
сопровождение моделей, а не бумажных документов, поэтому этот процесс
привязан к использованию конкретных средств моделирования (UML), а также
конкретной технологии проектирования и разработки (объектно-
ориентированный анализ, object-oriented analysis, OOA, объектно-
ориентированное программирование, object-oriented programming, OOP).
5. Microsoft Solution Framework (MSF)
MSF сходна с RUP, так же включает четыре фазы: анализ,
проектирование, разработка, стабилизация, является итерационной,
предполагает использование объектно-ориентированного моделирования. [8].
MSF в сравнении с RUP в большей степени ориентирована на разработку
бизнес-приложений. Microsoft Solutions Framework является наиболее
сбалансированной технологией, ориентированной на проектные группы малых
и средних размеров. MSF не накладывает никаких ограничений на
используемый инструментарий и содержит рекомендации весьма общего
характера. Однако, эти рекомендации могут быть использованы для построения
конкретного процесса, соответствующего потребностям коллектива
разработчиков.
6. Extreme Programming (XP)
Экстремальное программирование является самым новым среди
рассматриваемых методологий, сформировалось в 1996 году. В основе
методологии командная работа, эффективная коммуникация между заказчиком
60
и исполнителем в течение всего проекта по разработке ИС, а разработка ведется
с использованием последовательно дорабатываемых прототипов.
Основными критериями для выбора стандарта ЖЦ будут:
актуальность и современность используемых методик контроля
разработки
разработка в итерационном режиме с возможностью контролировать
риски
и выполнения самого проекта на неких контрольных точках,
отсутствие дополнительных требований по моделированию процесса
разработки и внедрения.
Extreme Programming хорошо подходит для проектных групп малого
размера и для небольших систем с часто изменяемыми требованиями. Основная
проблема XP - сопровождение. В случае текучки кадров в коллективе
разработчиков значительная часть проектной информации может быть утеряна
из-за практически отсутствующей документации.
7. COBIT
COBIT (Control Objectives for Information and related Technology) – подход
к управлению информационными технологиями, созданный Ассоциацией
контроля и аудита систем (Information Systems Audit and Control Association -
ISACA) и Институтом руководства ИТ (IT Governance Institute - ITGI) в 1992
году. Он предоставляет менеджерам, аудиторам и ИТ пользователям набор
утверждённых метрик, процессов и лучших практик с целью помочь им в
извлечении максимальной выгоды от использования информационных
технологий и для разработки соответствующего руководства и контроля ИТ в
компании.
Концепция стандарта предполагает построение механизмов управления
ИТ исходя из того, какая информация необходима для достижения бизнес-
целей. При этом информация рассматривается как результат использования ИТ
ресурсов, управление которыми осуществляется в рамках ИТ процессов. ИТ
61
ресурсы включают в себя приложения, информацию (данные в любой форме),
инфраструктуру, персонал.
8. ГОСТ 34.601-90
Данный стандарт распространяется на автоматизированные системы и
устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится
описание содержания работ на каждом этапе. Стадии и этапы работы,
закрепленные в стандарте, в большей степени соответствуют каскадной модели
жизненного цикла [14]
Поскольку в рассматриваемой выпускной квалификационной работе,
модуль разрабатывается с использованием каскадной модели, разработка
прототипов не рассматривается ввиду ускорения разработки, для разработки
модуля был выбран стандарт данный стандарт, стандарт ГОСТ 34.601-90
Ниже представлена таблица со всеми стадиями и этапами работ по
данному стандарту:
Таблица 5
Стадии и этапы работ стандарта ГОСТ 34.601-90
Стадии
Этапы работ
1. Формирование
требований к АС
1.1. Обследование объекта и обоснование необходимости
создания АС
1.2. Формирование требований пользователя к АС
1.3. Оформление отчета о выполненной работе и заявки на
разработку АС (тактико-технического задания)
2. Разработка
концепции АС
2.1. Изучение объекта
2.2. Проведение необходимых научно-исследовательских
работ
2.3. Разработка вариантов концепции АС и выбор варианта
концепции АС, удовлетворяющего требованиям
пользователя
2.4. Оформление отчета о выполненной работе
3. Техническое
задание
3.1. Разработка и утверждение технического задания на
создание АС
4. Эскизный
проект
4.1. Разработка предварительных проектных решений по
системе и ее частям
62
4.2. Разработка документации на АС и ее части
5. Технический
проект
5.1. Разработка проектных решений по системе и ее частям
5.2. Разработка документации на АС и ее части
5.3. Разработка и оформление документации на поставку
изделий для комплектования АС и (или) технических
требований (технических заданий) на их разработку
5.4. Разработка заданий на проектирование в смежных
частях проекта объекта автоматизации
6. Рабочая
документация
6.1. Разработка рабочей документации на систему и ее
части
6.2. Разработка или адаптация программ
7. Ввод в
действие
7.1. Подготовка объекта автоматизации к вводу АС в
действие
7.2. Подготовка персонала
7.3. Комплектация АС поставляемая изделиями
(программными и техническими средствами, программно-
техническими комплексами, информационными изделиями)
7.4. Строительно-монтажные работы
7.5. Пусконаладочные работы
7.6. Проведение предварительных испытаний
7.7. Проведение опытной эксплуатации
7.8. Проведение приемочных испытаний
8. Сопровождение
АС
8.1. Выполнение работ в соответствии с гарантийными
обязательствами
8.2. Послегарантийное обслуживание
Для ускорения процесса разработки, а также ввиду участия в данной
выпускной квалификационной работе только дипломника, которым и
принимаются все решения, было принято решение отказаться от ряда стадий и
этапов данного стандарта, в частности это относится к стадии рабочей
документации.
Конечным действие будет являться внедрение. Само внедрение является
общим понятием и для него существуют разные стратегии реализации, которые
63
напрямую зависят от срока исполнения и качества ИС, получаемой на выходе.
Существуют четыре основные стратегии внедрения системы:
Параллельная стратегия - когда одновременно работают старая и новая
система, и их выходные результаты сравниваются. Таким образом
происходит процесс адаптации, после чего осуществляется переход на
новую систему.
"Скачок" - это резкий переход от старой системы к новой без
дополнительных проверок и с полным отказом от старой системы.
"Пилотный проект" это наиболее часто используемая стратегия.
"Пилотный проект" - это тактика "скачка", но применяемая к
ограниченному числу процессов. Область применения стратегии -
небольшой участок деятельности. Такой подход снижает риск и
наиболее надежен.
"Узкое место" - это малая часть производственного процесса. При
использовании подхода "узкое место" план внедрения выполняется
только для "узкого места" и для людей, работающих в нем.
Поскольку в компании ООО «ТД ОРИОН» решили полностью уйти от
предыдущего, старого и не эффективного сайта, будет применена стратегия
«скачок».
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Любой проект по созданию информационной системы предприятия
всегда включает множество задач, связанных с общим управлением проектом,
разработкой ПО, проектированием ИС, внедрением, каждая из которых сама по
себе является проектом с присущими ему особенностями. Поэтому в ходе
разработки существуют различные риски.
Риски заказчика связаны с неполным достижением целей проекта и не
эффективно израсходованными средствами, а риски исполнителя - с
возможностью резкого превышения фактической себестоимости работ по
64
сравнению с плановой. Необходимость ведения параллельных и подчас
принципиально отличающихся по своему характеру работ приводит к тому, что
многократно возрастает уровень риска проекта.
Наиболее характерные риски и методы из минимизации приведены в
таблице 6,
Таблица 6
Возможные риски проекта и способы их минимизации
Виды рисков/
варианты
менеджмента
рисков
Снижение видов риска
Снижение вероятности
возникновения риска
Риски, связанные с
масштабом проекта.
Детальный анализ каждого
этапа работ, взаимодействия
участников, организации
работ.
Детальная проработанная
программа качества,
отработанное управление
конфигурацией проекта,
специальные процедуры
взаимодействия участников.
Риски, связанные с
недостаточным
опытом в сфере ИТ
Проведение обучения
пользователей, включая
руководство, соблюдение
технологий работы
Разработка и утверждение
концепции проекта на
возможно более ранней его
стадии.
Технические риски
проекта
Строгий отбор проектной
команды по
квалификационным
критериям. Обучение
участников проекта
технологии проектных работ,
инструментальными
средствами
Использование стандартов
предприятия на проектные
работы, разработка
стандартов проекта.
Организационные
риски проекта
Обучение участников
проекта, тренинги команды,
как можно более полная
формализация деятельности
Включение в команды
администратора проекта,
детально распределение
ролей в проекте.
Операционные
Многократное тестирование
Строгое выполнение
65
Виды рисков/
варианты
менеджмента
рисков
Снижение видов риска
Снижение вероятности
возникновения риска
риски проекта
созданных продуктов,
тщательная экспертиза
документов
процедур программы
качества.
В данной ВКР с учетом того что используется каскадная модель ЖЦ, а
также имеется строгое и точное ТЗ, максимально возможные риски, это ошибки
исполнителя в процессе разработки какого-либо из этапов. Устранение данных
рисков вполне простое, требуется тщательная проверка разработанного
материала перед переходом на следующий этап. При соблюдении ТЗ и
проверки этапов, проект будет сдан вовремя, без ошибок, и выполнением всех
условий и потребностей.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Интернет магазин, да и в целом любой сайт, обладает двумя типами
пользователей, первый – это администратор, который руководит и управляет
сайтом, и второй – это непосредственный пользователь сайта, клиент.
В данной ВКР группы пользователей разделены на 3 части, основным
пользователем является администратор, он имеет доступ ко всем системам,
файлам и папкам проекта, может получить доступ от других пользователей, а
также управлять модулями и всей системой в целом. Второй группой
пользователей являются менеджеры, данная группа обладает возможностью
обработки заявок, изменением контента сайта, товары/баннера/акции. И третей
группой лиц являются клиенты, то есть пользователи сайта, которые
пользуются им и совершают покупки, они имеют доступ только
66
непосредственно к общедоступным данным на сайте и возможностью
приобретения товара.
Ниже рассмотрим таблицу с более наглядным разграничением прав
доступа.
Таблица 7
Разграничение прав доступа
Группа
пользовател
ей
БД
MySQL
Файлы
систем
ы
Админ
панель
Контент
Корзина
Оформле
ние
заказа
Администрато
р
Полный
Полный
Полный
Полный
Полный
Полный
Менеджер
Отсутств
ует
Отсутств
ует
Частичн
ый
Полный
Полный
Чтение/зап
ись
Клиент
Отсутств
ует
Отсутств
ует
Отсутств
ует
Отсутств
ует
Чтение/за
пись
/удаление
Чтение/зап
ись
Защита от внешних угроз начинается с того что сам сайт находится на
удаленном сервере, защищенным физическими фаерволами и разным
антивирусным ПО. Так же осуществляется контроль прав доступа к данному
серверу. На станциях внутри компании так же установлены антивирусные
программы, а само подключение к серверу невозможно без специальных
доступов известных лишь пользователю данного ПК.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и ее описание
Информационная модель представляет собой процесс движения
информации в ИС. ИМ определяет основное содержание деятельности, а также
схему движения информации с момента её поступления до момента её вывода.
Со схемой информационной модели данной ВКР можно ознакомиться
ниже на рисунке 9.