4.1.6 Требования к защите информации от несанкционированного доступа

Объектами защиты в приложении являются:

а) пароль администратора;

б) информация о товаре;

в) информация о заказчике товара.

Для организации защиты выбранных объектов необходимо предусмотреть:

1) предоставлять доступ в администраторскую часть только после ввода пароля;

2) обеспечение хранения конфиденциальной информации в зашифрованном виде;

3) обеспечить передачу информации по открытым каналам связи в зашифрованном виде;

4) при выполнении опасных операций с данными (удаление, модификация) запрашивать подтверждение пользователя.

4.1.7 Требования по защите информации при авариях, требования по защите влияния от внешних воздействий

Необходимо предусмотреть возможность резервирования информации во избежание её потери при авариях (катастрофы природного и техногенного характера).

4.1.8 Требования по стандартизации и унификации

Приложение должно соответствовать современным принципам/технологиям проектирования.

База данных должна обеспечивать целостность, безопасность, резервируемость и сохраняемость данных.

Интерфейс должен поддерживаться всеми современными браузерами и корректно в них отображаться.

4.2 Требования к функциям (задачам), выполняемым приложением

Приложение должно обеспечивать выполнение следующих модулей:

1) Интерфейс пользователя;

1.1) Каталог (развернутый вид - в центре экрана, и краткая навигация, расположенная на сайд-баре);

1.2) Прайс-лист (краткое отображение всех товаров по категориям);

1.3) Меню оформления заказа;

1.4) Поиск товара;

1.5) Два меню отображения информации в шапке приложения (информация о магазине и доставке/ оплате товара)

2) Интерфейс администратора;

2.1) Модуль обеспечения авторизации (проверка логина и пароля);

2.2) Модуль для создания/ удаления/ редактирования каталогов (информации раздела, фото);

2.3) Модуль добавления/ редактирования/ удаления товара (информации о нем, фото,);

2.4) Модуль “Специального предложения” (товар который будет отображен на главной странице)

2.5) Модуль Обзора полученных заказов;

2.6) Модуль настройки интернет-магазина (общая, визуальная, доступа и информации о нем);

2.7) Модуль показа общей информация по магазину (количество продуктов и категорий, количество заказов и сумма продаж).

4.2.1 Для выполнения задачи 1.1) необходимо реализовать следующие функции:

а) функция каталога (наименование каталога/подкаталогов, отображение фото, информация о каталоге);

б) функция навигации по каталогу.

4.2.2 Для выполнения задачи 1.2) необходимо реализовать следующие функции:

а) функция прайс-листа (наименование каталога, наименование товара, цена).

4.2.3 Для выполнения задачи 1.3) необходимо реализовать следующие функции:

а) функцию корзины (иконка по нажатию на которую товар попадает в корзину, далее в меню корзины: наименование товара, количество штук(на выбор), цена одного товара, общая цена товаров в корзине, кнопка обновить (для пересчета общей суммы), кнопка выхода из корзины, кнопка “оформить заказ”)

б) меню брифинга корзины (располагается на сайд-баре, позволяет видеть сколько товаров у вас сейчас в корзине и на какую сумму, также позволяет вернутся обратно в развернутую корзину, для дальнейшего оформления заказа);

в) Меню контактной информации для связи с клиентом (включает пункты оформления информации о клиенте, делятся на обязательные(Ф.И.О) и необязательные(адрес) пункты);

4.2.4 Для выполнения задачи 1.4) необходимо реализовать следующие функции:

а) функция поиска товара;

4.2.5 Для выполнения задачи 1.5) необходимо реализовать следующие функции:

а) Модуль перевода меню (русский и английский, по умолчанию - русский);

4.2.6 Для выполнения задачи 1.6) необходимо реализовать следующие функции:

а) Меню информации - “О Магазине” - На этой странице возможно разместить, например, информацию о магазине, компании, правила предоставления услуг, контакты.

б) Меню информации - “Доставка и оплата” - На этой странице возможно разместить информацию о порядке доставки и оплаты заказов в интернет-магазине.

4.2.7 Для выполнения задачи 2.1) необходимо реализовать следующие функции:

а) функция проверки пароля (форма ввода пароля, в случае неправильного ввода, выводит сообщение об ошибке).

4.2.8 Для выполнения задачи 2.2) необходимо реализовать следующие функции:

а) Функция “категории”, позволяет добавлять/редактировать/удалять каталоги; после нажатия кнопки “добавить”, открывается окно в котором необходимо заполнить информацию о каталоге и выбрать логотип.

а) Функция “товары”, позволяет добавлять/редактировать/удалять товары; после нажатия кнопки “добавить”, открывается окно в котором необходимо заполнить информацию о товаре и загрузить 3 вида фото. В самом меню доступны функции изменения цены, доступности товара на складе и включения его в список продаж, также имеется кнопка, для переноса товара в специальные предложения.

Для выполнения задачи 2.4) необходимо реализовать следующие функции:

а) Функция “Специальные предложения” - включает в себя отображения товара, порядок отображения на главной странице и кнопку удалить и сохранить.

4.2.11 Для выполнения задачи 2.5) необходимо реализовать следующие функции:

а) Функция “Заказы” Включает в себя таблицу с заполненными данными клиентов, о купле того или иного товара, дате и времени заказа, возможность удалить заказ после его выполнения.

Для выполнения задачи 2.6) необходимо реализовать следующие функции:

а) Вкладка “общие” включает в себя: изменения названия сайта, url, контактный емейл магазина и емейл на который будут приходить уведомления о полученных заказах. Также включает в себя настройки валют: обозначение валюты (например $), и код валюты (например USD).

б) Функция “оформление” позволяет задать количество товаров на странице, количество столбцов при показе товаров, цвета используемые в таблице, включить корзину, показывать популярные товары в пустых категориях.

в) Функция “доступ к администрированию” - позволяет изменить данные для входа в администраторскую часть (логин и пароль)

г) Функция “дополнительная информация” - позволяет редактировать информацию о магазине, доставке и плате, которая потом будет отображена в соответствующих пунктах меню на главной странице.

Для выполнения задачи 2.7) необходимо реализовать следующие функции:

а) Функция выводит информацию о магазине(количество товаров, каталогов, продаж) в верхнем-правом углу, а также непосредственно после входа в режим администрирования.

Требования к видам обеспечения

1) Программное:

ПО, необходимое для установки приложения:

а) Windows Server или Linux

б) Apache web-server

в) MySQLServer

г) PHP как модуль web-сервера версии 4.3.0 и выше

д) PHP редактор

е) интернет браузер поддерживающий протокол http.

2) Аппаратное:

а) минимальный необходимый процессор - 133 МГц;

б) ОЗУ - 128мб;

в) доступное дисковое пространство - не менее 300 Мб;

г) графический адаптер, для вывода изображения на экран.

3) Организационно-методическое:

Физический доступ к серверам на которых установлено приложение, должен быть ограничен.

Стойки сервера должны находиться в изолированном помещении, доступ к которым имеют только администраторы или обслуживающий персонал.

5. Порядок контроля и приемки системы

Порядок выполнения и приемки этапов разработки приложения должен соответствовать требованиям ГОСТ 21.101-97.

Поставка приложения заказчику должна осуществляться комплексно после проведения всего цикла испытаний.

Техническая документация при поставке должна соответствовать ЕСПД и ГОСТ 2.114-95.

Настоящее ТЗ может уточнятся и дополнятся по согласию сторон.

6 Требованию к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

1) Запуск web-сервера Apache;

2) Создание учетной записи администратора;

3) Установка приложения

7. Требования к документированию

4. Технологическая часть

4.1 Современные методы и средства тестирования web-приложений

Тестирование программного обеспечения-- процесс исследования, испытания программного продукта, имеющий две различные цели:

· продемонстрировать разработчикам и заказчикам, что программа соответствует требованиям;

· выявить ситуации, в которых поведение программы является неправильным, нежелательным или не соответствующим спецификации.

Существующие на сегодня методы тестирования программного обеспечения не позволяют однозначно и полностью выявить все дефекты и установить корректность функционирования анализируемой программы, поэтому все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого программного обеспечения.

В настоящее время все большее распространение получают приложения, взаимодействующие с пользователем посредством Web-интерфейса. Такие приложения не занимаются непосредственно отображением пользовательского интерфейса, а перекладывают эту задачу на посредника -- как правило, в этой роли выступает Web-браузер, получающий от приложения документы в формате HTML, отображающий их в своем окне, и передающий приложению информацию о различных действиях, совершаемых пользователем. В зависимости от этих действий приложение создает и передает Web-браузеру новую страницу HTML, и работа продолжается дальше.

Страницы HTML, как правило, генерируются приложением в процессе работы; при этом могут использоваться различные шаблоны, задающие стиль и структуру документа, в то время как содержательная часть создается динамически. При наполнении страницы может использоваться некоторое хранилище данных (в роли которого, как правило, выступает база данных). Такой подход широко распространен в системах управления информацией (Content Management Systems, CMS), различных интернет-форумах, и т.п. Отделение данных от остальной инфраструктуры приложения обеспечивает возможность удобно и быстро изменять содержимое интернет-порталов и сайтов; в то же время изменение оформления или структуры страниц не требует какой-либо работы с данными.

Для написания программ, генерирующих страницы HTML с использованием данных из внешнего хранилища, широко используются скриптовые языки программирования, например, Perl и PHP. Такие языки являются интерпретируемыми, что позволяет программистам не беспокоиться о том, на какой программно-аппаратной платформе будет работать приложение (естественно, при условии, что для данной платформы существует интерпретатор соответствующего языка).

Как и для любого программного обеспечения, для Web-приложений важным является вопрос обеспечения их качества -- программы должны выдавать те страницы, которые ожидает пользователь. Таким образом, необходимо решать задачу функционального тестирования таких программ (других важных аспектов проверки качества Web-приложений, например, нагрузочного тестирования, мы в этой статье касаться не будем). Кроме того, большинство Web-приложений постоянно развиваются и модифицируются, поэтому важным является наличие регрессионных тестов, позволяющих удостовериться, что в результате внесения изменений функциональность приложения не нарушается.

Непосредственное тестирование Web-приложения человеком (заключающееся, фактически, в переходе по различным ссылкам внутри приложения и анализа отображаемых страниц) отнимает много времени и в случае больших приложений малоэффективно. Под «большими» здесь стоит понимать программы, не только содержащие много строк кода, но и обладающие большим количеством входных параметров, работающие с базами данных сложной структуры и с большим количеством записей. При разработке таких программных продуктов вопрос об автоматизации процесса их тестирования стоит особенно остро.

Такой процесс формальной проверки, иливерификации, может доказать, что дефекты отсутствуют с точки зрения используемого метода. (То есть нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапахжизненного цикла программного обеспечения.)

Существует множество подходов к решению задачи тестирования и верификации программного обеспечения, но эффективное тестирование сложных программных продуктов-- это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.

Качество программного обеспеченияможно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:

· надёжность

· сопровождаемость,

· практичность,

· эффективность,

· мобильность,

· функциональность.

Состав и содержание документации, сопутствующей процессу тестирования, определяется стандартом IEEE 829-1998.

Тестирования программного обеспечения

Существует несколько признаков, по которым принято производить классификацию видов тестирования. Обычно выделяют следующие:

По объекту тестирования

· Функциональное тестирование

· Тестирование производительности

· Нагрузочное тестирование

· Стресс-тестирование

· Тестирование стабильности

· Конфигурационное тестирование

· Юзабилити-тестирование

· Тестирование интерфейса пользователя

· Тестирование безопасности

· Тестирование локализации

· Тестирование совместимости

По знанию системы

· Тестирование чёрного ящика

· Тестирование белого ящика

· Тестирование серого ящика

По степени автоматизации

· Ручное тестирование

· Автоматизированное тестирование

· Полуавтоматизированное тестирование

По степени изолированности компонентов

· Модульное тестирование

· Интеграционное тестирование

· Системное тестирование

· Альфа-тестирование

· Дымовое тестирование(англ.smoketesting)

· Тестирование новой функции(newfeaturetesting)

· Подтверждающее тестирование

· Регрессионное тестирование

· Приёмочное тестирование

· Бета-тестирование

По признаку позитивности сценариев

· Позитивное тестирование

· Негативное тестирование

По степени подготовленности к тестированию

· Тестирование по документации (формальное тестирование)

· Интуитивное тестирование (англ. adhoctesting)

Большинство из существующих подходов к тестированию Web-приложений являются тестированием по принципу "черного ящика" (4.1.2). Все, чем обладает тестировщик -- это само приложение, с которым можно взаимодействовать, например, через Web-браузер, и список требований, которым приложение должно удовлетворять. Тестирование заключается в переходе по различным ссылкам внутри приложения и анализе получаемых страниц. Существуют инструменты для автоматизации этих процессов, однако ведущая роль в разработке тестов все-таки отводится человеку.

Существует много решений, позволяющих записывать сценарии поведения пользователя (т.е. цепочку ссылок, по которым осуществлялся переход) -- IBM RationalRobot, HP WinRunner, Empirix e-TESTи другие. Записанный единожды сценарий может далее воспроизводиться автоматически. Однако создание сценариев -- трудоемкое занятие, причем отдельной задачей является анализ требований к приложению с целью определить, какие именно сценарии должны быть созданы для обеспечения хорошего качества тестирования. Некоторые инструменты (например, компонент PureAgent в системе PureTest) позволяют создавать сценарии на основе действий реальных пользователей, работающих с приложением. Однако и при таком подходе при достаточно большом количестве пользователей встает вопрос о выборе из множества возможных сценариев относительно небольшого набора, который, тем не менее, обеспечит хорошее качество тестирования.

Существуют инструменты, позволяющие автоматически генерировать ссылки для обращения к приложению по протоколу HTTP, получать соответствующие страницы и производить их анализ. Однако при генерации ссылок также обычно применяется подход «черного ящика» -- исходный код приложений не анализируется, а ссылки, которые необходимо генерировать, должен описать тестировщик с использованием специфических для каждого инструмента средств. Например, eValid позволяет перебирать значения параметров для скриптов, которые будут подставляться в создаваемые ссылки, но список параметров с возможными значениями для каждого скрипта должен составлять тестировщик. При достаточно большом количестве скриптов и параметров создание такого списка потребует много времени; кроме того, список должен постоянно поддерживаться в актуальном состоянии -- тестировщик должен следить за изменением состава скриптов и их параметров. Инструмент Puffinпозволяет генерировать для параметров произвольные значения, однако такой подход во многих случаях сильно снижает качество тестирования по сравнению с ручным заданием значений. В случае Puffin, опять же, список имен параметров должен составлять и поддерживать тестировщик. Кроме того, существующие инструменты не предоставляют удобных средств для перебора различных комбинаций параметров, а во многих случаях интерес представляет именно перебор комбинаций, поскольку разные сочетания параметров могут задействовать различные части приложения.

Многие инструменты анализируют получаемые в процессе тестирования страницы, извлекая из них ссылки на другие части приложения и имитируя переход по ним (опять же, с дальнейшим анализом получаемых страниц; например, для таких целей предназначен компонент 'WebCrawler', входящий в PureTest). Таким образом, осуществляется переход по всем ссылкам, которые могут быть достигнуты, начиная с определенной страницы. Поскольку все части приложения, как правило, взаимосвязаны, то в идеале, начав с некоторой стартовой страницы и посетив все достижимые из нее ссылки, можно протестировать всю функциональность приложения, доступную пользователю. Однако число ссылок может быть чрезвычайно велико, и лавинообразно расти с увеличением числа посещенных страниц. К сожалению, современные средства перехода по ссылкам достаточно примитивны и просто осуществляют переходы по всем встреченным ссылкам (ввиду чего они часто используются при нагрузочном тестировании). Настройка либо доработка инструментов для более «интеллектуального» выбора ссылок, по которым надо осуществлять переходы, требует тщательного анализа самого приложения.

Проверка правильности может производиться путем сравнения получаемых страниц с эталонными. Такие проверки полезны при регрессионном тестировании, однако если что-то изменилось в структуре страниц с момента создания эталонов, то эталоны должны быть созданы заново, а проверка корректности страницы -- произведена вручную.

Кроме того, во многих случаях стоит цель тестирования не только части приложения, занимающейся формированием страниц HTML, но всего программного комплекса, неотъемлемой частью которого является постоянно изменяющаяся база данных. Сравнение страниц целиком в таких случаях не оправдано. Например, в случае приложения, формирующего страницу с ежечасно обновляемыми новостями, документы, выдаваемые по одному и тому же запросу в различные моменты времени, с большой вероятностью будут отличаться. Можно поддерживать еще и заранее заданный набор данных, на котором проводится тестирование, однако это не избавляет от проблем в случае изменения структуры или оформления страниц.

В качестве альтернативы предлагаются менее строгие проверки; так, уже упоминавшийся eValid позволяет производить более 20 сравнений, среди которых можно отметить следующие:

· 'URL' -- проверка ссылки, на которой оказался пользователь после совершения определенных действий, записанных в сценарии;

· 'Title' -- проверка названия страницы;

· 'Elements' -- проверка числа элементов в DOM-модели страницы;

· 'ByteSize' -- проверка размера страницы;

· 'LastModifiedDate' -- проверка даты последнего изменения страницы;

· 'Checksum' -- проверка контрольной суммы для текста страницы;

· 'Text' -- проверка выделенных участков текста страницы;

· 'ScreenRectangle' -- сравнение изображения определенного участка страницы с тем, что наблюдал тестировщик во время записи сценария.

Остальные проверки являются вариациями проверки части страницы как изображения либо являются комбинациями указанных проверок.

Можно отметить, что несмотря на достаточно большое количество доступных проверок, ни одна из них не пригодна в случае, когда изменяется содержательная часть страницы -- часть проверок (такие, как 'Title' и 'URL') могут вообще не зависеть от этой составляющей документа, а другие ('ByteSize', 'Checksum', 'ScreenRectangle') с большой вероятностью сообщат об ошибке (т.е. об отличии полученного на новых данных результата от эталонного), но такие сообщения скорее всего не будут свидетельствовать о реальном нарушении функциональности приложения.

Существуют и более сложные подходы к разработке тестов для Web-приложений, позволяющие абстрагироваться от различных аспектов, связанных непосредственно с языком разметки HTML, и генерировать тесты на основе формальной модели данных, передаваемых приложению -- см., например. Однако такие подходы трудоемки и требуют достаточно высокой квалификации тестировщиков.

В то же время исходный код Web-приложений, основанных на скриптовых языках, обладает рядом особенностей, позволяющих на основе его анализа автоматически генерировать ссылки для тестирования, что и будет продемонстрировано в данной статье. При этом соответствие кода некоторым условиям существенно повышает качество создаваемых тестов, что может быть учтено при разработке приложения. Также будут рассмотрены методы и инструменты, которые можно применять в процессе анализа генерируемых страниц для вынесения вердикта об успешности тестирования. Основная цель предлагаемого подхода -- быстрое создание тестового набора, покрывающего достаточно большую часть функциональности приложения, не требующего больших затрат по поддержанию тестов в актуальном состоянии, но в то же время способного выявлять достаточно большой спектр ошибок

Уровни тестирования. Модульное тестирование-- тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками программного обеспечения.

· Интеграционное тестирование-- тестируются интерфейсы между компонентами, подсистемами или системами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.

· Системное тестирование-- тестируется интегрированная система на её соответствие требованиям.

· Альфа-тестирование-- имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться программа.

· Бета-тестирование-- в некоторых случаях выполняется распространение предварительной версии (в случае проприетарного программного обеспечения иногда с ограничениями по функциональности или времени работы) для некоторой большей группы лиц с тем, чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей.

Часто для свободного и открытого программного обеспечения стадияальфа-тестирования характеризует функциональное наполнение кода, абета-тестирования-- стадию исправления ошибок. При этом как правило на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям.

В зависимости от доступа разработчика тестов к исходному коду тестируемой программы различают «тестирование (по стратегии) белого ящика» и «тестирование (по стратегии) чёрного ящика».

При тестировании белого ящика (также говорят--прозрачного ящика), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого программного обеспечения. Это типично для модульного тестирования, при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции-- работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрикипокрытия кода или мутационное тестирование.

При тестировании чёрного ящика, тестировщик имеет доступ к программе только через те жеинтерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов, с уверенностью в том, все ли идёт правильно, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок мыши. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе. Обычно в данном виде тестирования критерий покрытия складывается из покрытия структуры входных данных, покрытия требований и покрытия модели (в тестировании на основе моделей).

При тестировании серого ящика разработчик теста имеет доступ к исходному коду, но при непосредственном выполнении тестов доступ к коду, как правило, не требуется.

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «чёрного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

Бета-тестирование в целом ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию). Таким образом, термин «бета-тестирование» может указывать на состояние программы (ближе к выпуску чем «альфа»), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. То есть, тестировщик может продолжать работу по тестированию белого ящика, хотя программа уже «бета-стадии», но в этом случае он не является частью «бета-тестирования».

4.2 Тестирование функциональности

Для проверки корректного выполнения программой функций, заложенных в техническом задании, были составлены тестовые наборы, показанные в таблицах 4.1, 4.2, 4.3, 4.4.

Таблица 4.1 - Тестовые наборы для проверки функциональности авторизации

№ Теста	Действие	Ожидаемый результат	Отметка о выполнении
1	Ввод логина и пароля Login: admin Password: admin (ввод корректной информации)	Авторизация и вход на страницу администратора	проверено
2	Ввод логина и пароля Login: anonim Password: admin (ввод некорректной информации - неверный логин)	Сообщение о неправильно введенном логине или пароле	проверено
3	Ввод логина и пароля Login: admin Password: password (ввод некорректной информации - неверный пароль)	Сообщение о неправильно введенном логине или пароле	проверено

Таблица 4.2 - Тестовые наборы для проверки администрирования каталога и товаров

№ Теста	Действие	Ожидаемый результат	Отметка о выполнении
1	Выбор «Категории и товары»	Вывод меню редактирования каталога и товаров	проверено
2	Выбор «Добавить» категорию	Вывод формы для заполнения данных для новой категории	проверено
№ Теста	Действие	Ожидаемый результат	Отметка о выполнении
3	Заполнить форму и выбрать «Сохранить»	Создание новой категории	проверено
№ Теста	Действие	Ожидаемый результат	Отметка о выполнении
4	Выбор «Edit»	Вывод формы для редактирования данных о категории	проверено
5	Выбор «добавить» товар	Вывод формы для заполнения данных для нового товара	проверено
6	Заполнить форму и выбрать «Сохранить»	Добавление нового товара в выбранной категории	проверено
7	Выбор «кнопки - для удаления товара»	Удаление выбранного товара	проверено
8	Выбор названия товара	Вывод формы для редактирования данных	проверено
9	Выбор «кнопки - специальные предложения»	Перенос товара в меню «специальные предложения»	проверено

Таблица 4.3 - Тестовые наборы для проверки функциональностипоиска

№ Теста	Действие	Ожидаемый результат	Отметка о выполнении
1	Поиск товара по фразе, например: AMD	Вывод товара, в названии или описании которого упоминается данная фраза.	проверено
2	Поиск товара по фразе, заведомо несуществующей	Вывод сообщения о том, что ничего не найдено	проверено

Таблица 4.4 - Тестовые наборы для проверки функциональности закупки

№ Теста	Действие	Ожидаемый результат	Отметка о выполнении
1	Выбор категории: например AMD	Вывод товаров в данной категории и описание категории	проверено
2	Выбор товара: например процессор Athlon II	Вывод информации о товаре	проверено
3	Нажатие на кнопку “в корзину”	Вывод корзины	проверено
4	Установка количества товаров равным 20, и нажать кнопку обновить	Сумма заказа умножится на 20	проверено
5	Установка количества товаров равнымили меньше 0, и нажать кнопку обновить	Корзина очистится	проверено
6	Подтверждение заказа	Вывод формы для заполнения контактной информации	проверено
7	Ввод информации во все поля которые обязательные для заполнения	Добавление данных о заказе и покупателе в Базу Данных	проверено
8	Заполнение не всех обязательных полей	Вывод сообщения о незаполненных полях	проверено

Представленные в таблицах тесты позволили проверить программу и убедиться в корректном выполнении функционала.

5. Экономическое обоснование проекта

5.1 Маркетинговые исследования предприятия

Интернет-торговля - занятие очень выгодное. По крайней мере, должно быть таким в теории. Владельцу интернет-магазина не надо тратить деньги на аренду торговых площадей, закупку торгового оборудования, найм армии продавцов и консультантов. Вся информация представлена на сайте - и сам покупатель ходит среди "виртуальных полок" и выбирает, что ему нужно. Прибавьте к этому огромную потенциальную аудиторию рунета - десятки миллионов человек из России и стран СНГ. Вряд ли хоть один реальный магазин способен похвастаться столь большим числом потенциальных покупателей.

На практике придется побороться, чтобы клиенты выбрали именно наш магазин, а не торговую площадку конкурента. Сегодня Интернет-торговля стала обыденным явлением. Сотни магазинов предлагают тысячи товаров. Купить в интернете можно практически все, за исключением, наверно, путевки в космос. И конкуренция между магазинами - огромная. В борьбе за покупателя приходится обращать внимание на все - вплоть до мелочей.

Успех современного Интернет-магазина, обеспечивается результативным решением двух основных задач. Первая - привлечь на сайт магазина достаточное количество потенциальных покупателей. Вторая - перевести как можно больше посетителей из категории "потенциальных покупателей" в категорию реальных клиентов. Статистическое соотношение "посетители/покупатели" называется "уровнем конверсии", и чем выше этот показатель, тем (при прочих равных условиях) успешнее Интернет-магазине. В данной статье мы осветим некоторые базовые факторы организации Интернет-торговли, которые повышают уровень конверсии и без которых представить успешный магазин крайне сложно.

К числу внутренних факторов успеха интернет-магазина относятся прежде всего Сервис, Ассортимент и Цены. О приоритетности этих факторов можно долго спорить. С экономической точки зрения, для людей с невысокими доходами (к числу которых относятся многие россияне) определяющим фактором будут цены. Но давайте посмотрим на портрет рунетчика - в большинстве своем это офисные работники, руководители предприятий, специалисты, небедные студенты и учащиеся. Люди более-менее обеспеченные. И поэтому для них важнее Сервис и Ассортимент. И за это они готовы переплачивать. Например, Ozon.ru - один из крупнейших интернет-магазиноврунета. Но многие товары в нем дороже, чем в других магазинах, например, в Bolero.ru. Тем не менее, продуманная ценовая политика - одна из составляющих успеха, пусть и занимающая третье место после Сервиса и Ассортимента.

При разработке интернет-магазина большое внимание должно уделяться юзабилити. Под этим термином понимается удобство торговой площадки для посетителя. Наиболее важным для юзабилити является система навигации по товарному ассортименту..

Все, о чем мы говорили в этой статье, относится к внутренним факторам успеха - к тому, как должен быть организован сайт интернет-магазина. Дизайн и функционал должны быть на высоком уровне, чтобы обеспечивать посетителю высокий уровень Сервиса. В свою очередь коммерческая идея предприятия (выраженная в Ассортименте и Ценах) должна обеспечивать его прибыльность.

5.2 Расходы по созданию и размещению магазина в сети интернет

Так как за основу берется бесплатная версия программного продукта, в затратную часть создания Интернет - магазина относятся такие расходы как: расходы по оплате электроэнергии, расходы по размещению магазина в сети Интернет (хостинг), заработная плата программиста и курьера, а также прочие всевозможные расходы на канцелярские товары и расходные материалы для компьютера. Такие расходы как, амортизация компьютера и оргтехники и прочие расходы, относящиеся к магазину.

Для предприятий 1 кВт / ч= 0,24

В месяц 0.24*526,5= 126,36 гривен.

Заработная плата программисту составляет 1600 гривен.

R_Пост = 2706,36- постоянные ежемесячные расходы.

Так как помещение и оборудование уже имеется в наличии рассчитаем годовую сумму амортизационных отчислений.

Годовая сумма амортизационных отчислений рассчитывается по формуле:

,

где Ф - первоначальная стоимость основных фондов по видам, грн.;

N_A - норма амортизации по видам основных фондов, в %.

Таким образом, годовая сумма амортизационных отчислений составляет 1503,2 гривны.

Исходя из того, что трудоёмкость создания информационной системы составляет 10 дней, рассчитываем амортизацию оборудования за этот период по формуле:

,

Рассчитаем сумму амортизационных отчислений для перечисленной группы оборудования с учетом числа календарных дней на разработку программного обеспечения (интернет - магазина) по формуле:

А = =41,2 грн.

Заработная плата программиста составляет 1600 грн. Соответственно, затраты на заработную плату включаемые в себестоимость программы с учетом работы над программой в течение 12 дней составят:

,

где ЗП_пр - заработная плата в месяц программиста, грн.;

Т_факт - число календарных дней на разработку интернет - магазина;

Д - число дней в периоде (месяц).

ЗП_пр = = 727,3 грн.

З_м= 501,36 гривен в месяц

Следовательно, затраты на период разработки программного продукта рассчитаем по формуле:

З_пр= ,

где З_м - ежемесячные затраты, грн.;

Т_факт - число календарных дней на разработку интернет - магазина;

Д - число дней в периоде (месяц).

Рассчитаем себестоимость программного продукта по формуле:

С_ст - себестоимость разработки программы

С_ст = З_пр + ЗП_пр + А

С_ст = 227,9+727,3+41,2 = 996,4 гривен.

Данная себестоимость является приблизительной, так как в ней не учтены некоторые детали, которые существенно не повлияют на итог.

С_ст ? 1000 гривен.

Исходя из нормального уровня рентабельности 20% мы можем определить цену разработанной нами программы:

,

где С_ст - себестоимость разработки программы;

R - планируемый уровень рентабельности.

Так как помещение и оборудование уже имеется в наличии, затраты на внедрение программного продукта составят 1200 гривен.

5.3 Выводы

В результате расчета затраты на создание данного программного продукта составили 2703 грн. и 2706,36- постоянные ежемесячные расходы.

Для снижения затрат, можно предложить следующие решения. Как видно, три четверти расходов представляют из себя затраты на оплату труда программиста. Снизить эти затраты, можно путем повышения эффективности труда программиста за счет использования более современных ЭВМ для работы, повышения удобства рабочего места и прочих факторов. Также при более бережном и аккуратном отношении к компьютерной технике возможно снизить затраты на ремонт, а так же уменьшить привлечение дополнительного персонала на обслуживание компьютеров.

6. Охрана труда и безопасность в черезвычайных ситуациях

В Украине главным нормативно-законодательным документом, определяющим требования безопасности и санитарно-гигиенические требования к организации рабочих мест операторов ЭВМ и работников, выполняющих обслуживание и ремонт ЭВМ, являются “Правила охраны труда во время эксплуатации ЭВМ”, утверждённые приказом Держнаглядохоронпраці от 10 февраля 1999 г №21 и зарегистрированные в Министерстве юстиции Украины 17 июня 1999 г под №382/3675. Этот документ устанавливает основные правила охраны труда и содержит ссылки другие нормативные документы.

6.1 Метеорологические условия при работе

Согласно ГОСТ 12.1.005-88 оптимальные параметры микроклимата для выполнения работы должны находиться в пределах, указанных в таблице 4.1.

Категорию работы учитываем по физической нагрузке. Работу сотрудников отдела отнесём к категории Iб (напряжённая работа).

Таблица 6.1 - Оптимальные нормы температуры, относительной влажности и подвижности воздуха

Категория Работы	Период года	Температура t, С	Относительная влажность, %	Скорость движения воздуха V, м/с
Напряжённая работа	Холодный	22-24	40-60	0,1
Напряжённая работа	Теплый	23-25	40 -60	0,1

Для обеспечения вышеуказанных оптимальных метеорологических условий в помещениях предусмотрена система отопления, вентиляции и кондиционирования согласно СНиП 2.04.05-90.

Расчет необходимого количества кондиционеров, должен проводиться по теплоизбыткам от машин, людей, солнечной радиации.

Режим работы кондиционера должен обеспечить максимально возможное поступление наружного воздуха, но не менее 50 % от производительности кондиционера.

При проектировании помещений, предназначенных для эксплуатации ЭВМ, необходимо предусматривать приточно-вытяжную вентиляцию. Подача воздуха должна производиться в верхнюю зону малыми скоростями из расчета создания подвижности воздуха на рабочем месте оператора ЭВМ менее 0,1 м/с, лучше через подшивной гофрированный потолок. Вытяжка - естественная из верхней зоны стены, противоположной оконным проемам.

Качественный состав воздуха: содержание кислорода в помещениях должно быть в пределах 21-22 %. Двуокись углерода не должна превышать 0,1 %, озон - 0,1 мг/м³, аммиак - 0,2 мг/м³, фенол - 0,01 мг/м³, хлористый винил - 0,005 мг/м³, формальдегид - 0,003 мг/м³.

6.2 Освещение

Работоспособность оператора ЭВМ во многом зависит от освещения. Неудовлетворительное освещение количественно или качественно утомляет не только зрение, но и вызывает утомление организма в целом, оказывает влияние на производительность труда оператора.

Для обеспечения нормального освещения применяются естественное и искусственное освещение, а также смешанное, которые нормируются санитарными нормами и правилами.

Естественное освещение наиболее благоприятно для человека ввиду его высокой диффузности (рассеянности) и спектральному составу. Поэтому, его следует использовать во всех случаях для освещения помещений. По конструктивным особенностям естественное освещение подразделяется на боковое, верхнее и комбинированное.

Все производственные помещения с постоянным нахождением в них людей, в соответствии с санитарными нормами и правилами СНиП II-4-79, имеют естественное освещение.

В помещениях применяется общее искусственное освещение, в холодные периоды года - совмещенное.

В качестве источников света рекомендуется использовать люминесцентные лампы мощностью 40 Вт или энергоэкономные мощностью 36 Вт типа ЛБ, ЛХБ, или ЛЕЦ как наиболее эффективные и приемлемые с точки зрения спектрального состава, цветовая температура (Т_ца) излучения которых находится в диапазоне 3500-4200 К.

Согласно СниПII-4-79, допустимая величина дискомфорта, одного из качественных параметров ОУ регламентируемого для ограничения прямой блёскости, не должна превышать 15. При проектировании ОУ следует пользоваться инженерным методом оценки слепящего действия ОУ по дискомфорту.

Величина коэффициента пульсации не должна превышать 10 %, для чего следует применять многоламповые светильники с компенсирующими ПРА, осуществлять расфазировку светильников при электромонтаже ОУ.

Для освещения дисплейного класса рекомендуется применять светильники серии ЛП013, ЛП031, ЛП033 исполнение 001 и 006, ЛС002, ЛС004. С металлической экранирующей решеткой и непрозрачными боковинами.

Расчет естественного освещения сводится к выбору вида освещения, определению (выбору) коэффициента естественной освещенности и расчету площадей светопроёмов.

Выполним расчёт необходимой площади светопроёмов для помещения с размерами в плане a х b = 4 х 10 м и высотой H = 3 м. Количество рабочих мест n = 4. При нормах 6 м² на одного человека имеем:

S = a * b = 4*10 = 40 м²>24 м².(4.1)

Расчет проведём по методике, изложенной в справочной и методической литературе. В расчетах использованы нормативные материалы по производственному освещению (СНиП II - 4 - 79).

В основу расчета положена известная зависимость:

,(4.2)

откуда искомая площадь светопроёмов:

,(4.3)

где S_n = 40 м² - площадь помещения;

e_min = 15 - нормируемый параметр при боковом освещении;

? =15 - световая характеристика;

K_з = 1,2 - коэффициент запаса;

K_зд = 1,0 - коэффициент, учитывающий затемнение окон, противостоящими зданиями;

r₁ = 2,2 - коэффициент, учитывающий влияние отраженного света при боковом освещении;

ф₀ - коэффициент светопропускания.

Определим коэффициент светопропускания:

(4.4)

где ф₁,ф₂,ф_3,ф₄,ф₅ - коэффициенты, принимаемые из справочного материала.

Найденные данные подставим в формулу (5.3) и получим результат:

Помещение методистов имеет одно окно с размерами 2 х 1,3 м, что не удовлетворяет нормам естественного освещения. Габариты помещения не позволяют увеличить площадь бокового оконного проёма до расчётного значения.

Поэтому в помещении методистов необходимо применять общее искусственное освещение, а каждое рабочее место рекомендуется оснастить индивидуальными настольными лампами.

Аналогичным образом можно провести расчёт естественного освещения и для других помещений.

Расчет Общего искусственного освещения

Искусственное освещение помещений поменяется в тех случаях, когда естественный свет недостаточен (вечернее время) либо он по условиям производства отсутствует.

Рассчитаем общее люминесцентное освещение для помещения, если

Для расчета общего люминесцентного освещения используем метод светового потока:

, (4.5)

где E_н= 500 Лк - нормируемая освещенность на рабочих местах;

S_n = 40 м²- расчетная поверхность освещения;

K_з = 1.5 - коэффициент запаса;

Z = 1.2 - коэффициент неравномерности освещения;

n = 12 - количество ламп;

з - коэффициент использования светового потока.

Определим коэффициент использования светового потока:

з = F(i), (4.6)

где i - индекс помещения, вычисляемый по формуле (4.7).

(4.7)

Тогда, подставив I в формулу (4.6), получим з = 0.65.

Найденные данные подставим в формулу (4.5) и получим результат:

Лм.

В качестве лампы принимаем лампу ЛХБ (люминесцентную холодно- белого света) с F_л = 3820 Лм и N = 65 Вт.

Мощность осветительной установки для помещения составит:

N_уст = N* n = 65 * 12 = 780 Вт.(4.8)

Аналогичным образом можно провести расчёт искусственного освещения для всех помещений отдела подготовки производства.

6.3 Ш;ум

В помещениях, предназначенных для эксплуатации ЭВМ, причиной шума являются компьютерные и периферийные устройства. В соответствии с требованиями ГОСТ 12.1.003-83, уровни звука в помещении, где работает обслуживающий персонал, не превышают 50 дБ.

Для снижения уровня шума согласно ГОСТ 12.1.012-90, потолок или стены выше панелей (1,5 - 1,7 м от пола), а иногда и стены и потолок должны облицовываться звукопоглощающим материалом с максимальным коэффициентом звукопоглощения в области частот 63-8000 Гц.

Дополнительным звукопоглощением в помещения могут быть занавеси, подвешенные в складку на расстоянии 15-20 см от ограждения, выполненного из плотной тяжелой ткани. Ширина занавеси должна быть в два раза больше ширины оконного проема.

6.4 Излучение от экрана монитора

ЭЛТ генерирует несколько типов излучения, в том числе: гамма тормозное, рентгеновское, радиочастотное, микроволновое, видимое, ультрафиолетовое и инфракрасное излучение. Уровни этих излучений не превышают действующих норм.

Конструктивное решение экрана дисплея таково, что рентгеновское излучение от экрана на расстоянии 10 см не превышает 100 мкР/ч.

В помещениях с дисплеями необходимо контролировать аэроионизацию. Норма содержания легких аэроионов обоих знаков от 1500 до 5000 в 1 см³ воздуха.

Следует учитывать, что мягкое рентгеновское излучение, возникающее при напряжении на аноде 20-22 кВ, а также напряжение на токоведущих участках схемы вызывает ионизацию воздуха с образованием положительных ионов, считающихся неблагоприятными для человека.

6.5 Техника безопасности

Так как помещения организации, где находятся ЭВМ, являются помещениями с повышенной опасностью поражения человека электрическим током, то при рассмотрении вопросов техники безопасности ограничимся рассмотрением электробезопасности.

Предусмотрены следующие меры электробезопасности:

- конструктивные меры электробезопасности;

- схемно-конструктивные меры электробезопасности;

- эксплуатационные меры электробезопасности.

Конструктивные меры электробезопасности

Конструктивные меры безопасности направлены на предотвращение возможности прикосновения человека к токоведущим частям.

Для устранения возможности прикосновения оператора к токоведущим частям, все рубильники установлены в закрытых корпусах. Применяется блочный монтаж.

Степень защиты оборудования соответствует IР44 (где 4 - защита от твердых тел размером более 1 мм; 4 - защита от брызг) согласно ПУЭ-87 и ГОСТ 14254-80.

Согласно ГОСТ 12.2.007.0-75^* принимаем I класс защиты от поражения электрическим током обслуживающего персонала потому, что компьютер имеет рабочую изоляцию и элементы заземления.

Схемно-конструктивные меры электробезопасности

Обеспечивают безопасность прикосновения человека к металлическим нетоковедущим частям электрических аппаратов при случайном пробое их изоляции и возникновения электрического потенциала на них.

Питание оборудования осуществляется от сети с заземленной нейтралью напряжением 220В и частотой 50 Гц.

Так как напряжение меньше 1000В, но больше 42 В, то согласно ГОСТ 12.1.030-81 в целях защиты от поражения электрическим током применяем зануление.

Зануление - преднамеренное электрическое соединение с нулевым защитным проводником металлических нетоковедущих частей, которые могут оказаться под напряжением.

По способу защиты от поражения электрическим током проектируемая система относится к I классу в соответствии с ГОСТ 12.2.007.0-75.

В электроустановках, при наличии напряжения от 24В до 380 В переменного тока и при работе в условиях с повышенной опасностью, применяется повторное защитное заземление (изолированная нейтраль), которое обеспечивает защиту человека от поражения электрическим током при соприкосновении с металлическими нетоковедущими частями, которые могут оказаться под напряжением в результате повреждения изоляции.

Эксплуатационные меры электробезопасности

Первичным источником питания ПЭВМ является однофазная сеть переменного тока напряжением 220В, с глухо-заземленной нейтралью, частотой 50 Гц, мощностью 2 кВт. Электропитание осуществляется от электроустановки (трансформатора) с регулированным напряжением под нагрузкой. Напряжение сети подается в распределительный шкаф.

В помещениях организации проложена шина повторного защитного заземления (заземляющий проводник) выполненная в соответствии с ГОСТ 12.1.030-81, которая металлически соединяется с заземленной нейтралью электроустановки.

Сопротивление заземляющего устройства, к которому присоединенанейтраль, не более 0,6 Ом. Шина повторного защитного заземлителя доступна для осмотра.

Для работы с устройствами под высоким напряжением необходимы следующие меры предосторожности:

Не подключать и не отключать разъемы кабелей при включенном напряжении сети;

Техническое обслуживание и ремонтные работы допускается производить только при выключенном питании сети;

К работе допускаются лица, обученные и имеющие группы допуска к работе с ЭВМ в соответствии с ПУЭ-87.

Пожарная безопасность - состояние объекта, при котором с установленной вероятностью исключается возможность возникновения и развития пожара, а также обеспечивается защита материальных ценностей.

Причинами, которые могут вызвать пожар в рассматриваемом помещении, являются:

- неисправность электропроводки и приборов;

- короткое замыкание электрических цепей;

- перегрев аппаратуры;

- молния.

Помещения организации по пожарной безопасности относятся к категорииД согласно ОНТП-24-86, так как в обращении находятся сгораемые вещества и материалы в холодном состоянии. Степень огнестойкости здания - II согласно СниП 2.01.02-85, класс помещений по пожарной опасности П-IIа, согласно ПУЭ-87.

Пожарная безопасность в соответствии с ГОСТ 12.1.004-91 обеспечивается системами предотвращения пожара, пожарной защиты, организационно-техническими мероприятиями.

Система предотвращения пожара:

- контроль и профилактика изоляции;

- наличие плавких вставок и предохранителей в электронном оборудовании;

- для защиты от статического напряжения используется заземление;

- молниезащита зданий и оборудования согласно РД 34.21.122-87.

Прогнозирование социально-экономических последствий чрезвычайных ситуаций техногенного характера причиненных пожаром

Рабочее место инженера находится в помещении размером 4 х 6 м² на втором этаже четырехэтажного здания. План помещения представлен на рис. 4.2, где 1, 2, 3, 5 - рабочие столы, 4 - шкаф, - розетки. Столы 1, 2, 5 имеют размеры - 1,2 х 0,7 м, стол 3 - 1,5 х 0,8 м, шкаф 4 - 1,0 х 0,6 м. Столы и шкаф сделаны из ДСП, значение величины поправочного коэффициента, который характеризует «доступность» горючего вещества строительного материала для его выгорания равна 0,5. В помещении работают 4 человека.

Определим радиусы внешней границы зоны общего пожара и зоны возможных частичных пожаров с использованием отношений:

,(4.9)

,(4.10)

гдеК - «тепловая нагрузка», т.е. плотность потока напряжения теплового излучения, которое поступает в помещение за единицу времени с одного квадратного метра площади строительного элемента в процессе его выгорания, Вт/м² (К233000 Вт/м²),