Розроблення модуля "Благодійний аукціон" на базі веб-технологій. Інтерфейс кампаній

Размещено на http://www.allbest.ru/

Харківський національний економічний університет

Факультет економічної інформатики

Кафедра інформаційних систем

Пояснювальна записка

до дипломного проекту бакалавра

на тему: "Розроблення модуля "Благодійний аукціон" на базі веб-технологій. Інтерфейс кампаній"

Виконав: студент 4 курсу, групи 6.04.52.13.01,

напряму підготовки 6.050101 "Комп'ютерні науки"

Кольган С.О.

Керівник: старший викладач

кафедри інформаційних систем

Конюшенко І.Г.

Рецензент: к.т.н., доц. кафедри інформаційних

технологій та мехатроніки ХНАДУ

Подоляка О.О.

Харків - 2015

• Зміст
• Реферат
• Вступ
• 1. Аналіз предметної області "Благодійний аукціон"

1.1 Коротка характеристика об'єкту управління "Nitralabs"

• 1.2 Опис предметної області
• 1.3 Аналіз існуючих програмних продуктів
• 2. Специфікація вимог до модуля "Облік компаній"
• 2.1 Глосарій
• 2.2 Розроблення варіантів використання
• 2.2.1 Діаграма варіантів використання
• 2.2.2 Специфікація варіантів використання
• 2.3 Специфікація функціональних та нефункціональних вимог
• 2.3.1 Функціональні вимоги
• 2.3.2 Нефункціональні вимоги
• 3. Проектні та технічні рішення
• 3.1 Математична постановка задачі
• 3.2 Проектування структури бази даних
• 3.2.1 Концептуальне інфологічне проектування
• 3.2.2 Проектування глобальної даталогічної моделі даних
• 3.2.3 Проектування фізичної моделі даних бази даних та її реалізація
• 3.3 Розроблення архітектури програмної системи
• 3.3.1 UML діаграма діяльності варіантів використання
• 3.3.2 UML діаграми класів
• 3.4 Тестування програмної системи
• 3.4.1 Тестування навантаження
• 3.4.2 Тестування властивостей
• 3.4.3 Регресійне тестування
• 3.4.4 Тестування графічного інтерфейсу користувача
• 3.5 Розгортання програмного продукту
• 4. Охорона праці
• 4.1 Аналіз санітарно-гігієнічних умов праці у приміщенні
• 4.2 Природне освітлення
• 4.3 Штучне освітлення
• 4.4 Кондиціювання
• 4.5 Пожежна безпека
• 4.6 Психологічна безпека
• 4.7 Техніка безпеки
• 4.7.1 Електробезпека
• 4.8 Пропозиції щодо поліпшення санітарних норм
• Висновки
• Список використаних джерел

• Реферат

Пояснювальна записка до дипломного проекту: 117 сторінок, 25 рисунків, 34 таблиць, 34 джерел.

Об'єктом проектування є функціональні елементи, архітектура, інформаційне і програмне забезпечення модуля благодійного аукціону.

Мета проектування - створення сучасного і повнофункціонального програмного продукту для проведення благодійних аукціонів.

Метод проектування - використання сучасних спеціалізованих програмних засобів та систем IBM Rational Rose, ERwin, Ramus Educational, RubyMine.

Створений додаток дозволяє здійснити проведення благодійних аукціонів. Крім цього програма надає зручне відображення результатів.

благодійність, аукціон, лот, case-діаграми, база даних, інтерфейс користувача.

Explanatory note to the diploma project: 117 pages, 25 figures, 34 tables, 34 sources.

The object is to design functional elements arhіtektura, informational and software module of analysis and assessing the module of charity auction..

The purpose of the design - creating of a modern and full-featured software package for holding a charity auction.

Design method - the use of modern specialized software and systems IBM Rational Rose, ERwin, Ramus Educational, RubyMine.

The created application allows the holding of charity auctions. In addition, the program provides convenient display of results.

charity, auction, lot, case-charts database user interface.



Вступ

Коли мова заходить про благодійність, то на думку чомусь спадає насамперед такі поняття як благородство, щедрість, широта натури, освіченість, любов до Батьківщини.

Під терміном добродійної діяльності згідно з Законом України "Про добродійність і добродійні організації", розуміється добровільна безкорислива діяльність добродійних організацій, яка не передбачає отримання прибутку від цієї діяльності. Що стосується терміну "добродійна організація", то у згаданому Законі під цим мається на увазі організація, головною метою діяльності якої є здійснення добродійної діяльності в інтересах суспільства або окремих категорій осіб.

Нажаль, у нашій державі такого поки що немає. Навіть навпаки - держава суворо стежить за бізнес-структурами, щоб зайвої копійки неоподаткована сфера не отримала.

В сфері благодійництва дуже велику роль відіграє поява спонсорства, яка більше відповідає роль сучасним уявленням про добродійність. Спонсор займається вкладенням грошей у щось або в когось. Але сфера його вкладень не обмежується тільки наукою або мистецтвом. Компанії вкладають гроші, в основному, в комерційні проекти. Дані дії виконуються в першу чергу для формування іміджу компанії та просування марки компанії на ринок. Спонсорство є ефективною комунікацією рекламного характеру. Тут можна зробити висновок того, що вкладання грошей робиться з метою отримання, врешті-решт, комерційного зиску.

Програма "Благодійний інтернет-аукціон" має за мету виручити якомога більше коштів для підтримки людей, які потребують допомоги завдяки проведенню інтернет торгів. Предметом розіграшу може бути звичайна кулькова ручка або малюнок маленької дівчинки, яка потребує допомоги.

В розіграшу лотів можуть приймати участь як благодійні компанії, так і звичайні користувачі мережі інтернет, які заінтересовані в питанні благодійництва.



1. Аналіз предметної області "Благодійний аукціон"

1.1 Коротка характеристика об'єкту управління "Nitralabs"

Лабораторію інтернет-технологій "Nitralabs" було створено у серпні 2007 року у місті Харкові. За організаційно-правовою формою це товариство з обмеженою відповідальністю.

Персонал компанії на даний момент нараховує 24 особи. Не дивлячись на малий час існування та на невеликий штат, ця компанія є значним конкурентом на ринку реалізації програмних продуктів. Вона займається створенням простих у використанні інструментів для ефективного управління бізнесом на основі програмних продуктів. У своїй практиці активно застосовує закордонний досвід та останні інноваційні тенденції й ідеї в області програмування.

Підписання трьохстороннього договору між центральним європейським офісом Microsoft в Ірландії та німецькою компанією Insight про взаємну співпраці та просування спільних рішень стало потужним поштовхом для розвитку компанії.

Основна мета, яка була визначена перед підприємством, - це впровадження в Україні останніх розробок, а також розвиток потужної школи виробничої підготовки для роботи з web-технологіями та бізнес-аналітикою.

Також компанія розробляє проекти для підприємств, працюючих у області FMCG (Fast Moving Consumer Goods - товари швидкого обігу повсякденного попиту), наприклад, програми, що надають аналітичну інформацію про торгових агентів, торгових точок, відвантажених товарах.

Розуміння бізнес-процесів з середини дозволяє запропоновувати клієнтам оптимальні вирішення проблем, що робить проекти максимально адаптованими к потребам клієнта. Розроблені інструменти враховують усі тонкості бізнесу та зорієнтовані на вирішення конкретних задач. Знання нових технології допомагає створювати складні багатофункціональні проекти, що легко масштабуються.

Функціонування компанії як єдине ціле забезпечує якісна комунікація між усіма учасниками розробки. Тому було вирішено надати можливість обміну ідеями та побажаннями, що виникають у ході робочого процесу, за допомогою веб-додатку. Кожен співробітник має можливість створити свою ідею, проголосувати та прокоментувати ідеї інших. Такі системи дозволяють прискорити процес опитування співробітників, скоротити час на заповнення різних анкет. Обговорення ідеї допомагає виявити унікальність та самодостатність кожного співробітника, реалізувати потенціал кожного.

Організаційна структура "Nitralabs" наведена на рис. 1.1.

Рис. 1.1. Організаційна структура підприємства "Nitralabs"

13

1.2 Опис предметної області

Благодійні фонди відіграють важливу роль в історії багатьох держав, підтримуючи соціально значущі, культурні, наукові програми.

Велика частина цивілізованих країн на рівні законодавства підтримує благодійність. Метою всякої благодійної діяльності - згладити наслідки соціальної нерівності. Одним з основних напрямків створення благодійного аукціону є надання допомоги дітям-сиротам і дітям, які залишилися без піклування батьків і проживають в дитячих будинках. Основний напрямок допомоги - сприяння соціальній та трудовій адаптації дітей, підвищення якості їх освіти і професійної орієнтації.

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

В розроблюваному модулі благодійного аукціону можна буде виконувати наступні дії:

вибір потребуючого;

створення нужденного;

створення лоту;

додання нужденного;

формування лоту;

запуск лоту;

формування звітності.

Дані вимоги будуть впроваджені в програмний продукт та нададуть користувачеві простоту та легкість при використанні розроблюваного модулю веб-сайту. Кожен представник благодійної організації безперешкодно зможе додати нового потребуючого допомоги до списку нужденних та створити під нього лот на отримання допомоги.

Для досягнення поставлених задач програмний продукт буде реалізований на наступних технологіях: Rails; jQuery; PhoneGap; CoffeScript; Html; Css; Bootstrap; MySQL; Trello; Capistrano; Git.

Метою бізнес-процесів є ведення бази даних та формування аналітичних звітів. Контекстна діаграма бізнес-процесу "Інтерфейс компаній" розроблена у стандарті IDEF0, яка наведена на рис. 1.1 [20]. Опис контекстної діаграми наведений у табл. 1.1.

Таблиця 1.1. Характеристика бізнес процесу "Облік компаній"

Назва характеристики	Значення
Ім'я бізнес-процесу	Інтерфейс компаній
Основні учасники	Представник компанії з питань благодійності, Адміністратор
Вхідна подія	Дані потребуючого допомоги
Вхідні документи	Інформація про тих хто потребує допомоги, заявки на отримання допомоги
Вихідна подія	Матеріальна підтримка нужденного
Вихідні документи	Реєстр тих хто отримав допомогу, анкета нужденного, створений лот

Рис. 1.1. Контекстна діаграма бізнес-процесу "Інтерфейс компаній"

Внаслідок декомпозиції контекстної діаграми бізнес-процесу "Інтерфейс компаній" були виділені наступні роботи:

вибір потребуючого;

створення нужденного;

створення лоту.

Діаграма першого рівня декомпозиції наведена на рис. 1.2, та її опис наведений у табл. 1.2.

Таблиця 1.2. Характеристика бізнес-процесу "Модуль компаній"

Назва характеристики	Значення
Ім'я бізнес-процесу	Модуль компаній
Основні учасники	Представник компанії з питань благодійності, адміністратор
Вхідна подія	Занесення нужденного до бази даних
Вхідні документи	Інформація про тих хто потребує допомоги, заявки на отримання допомоги
Вихідна подія	Занесення нужденного до реєстру отримавши допомогу, створення лоту
Вихідні документи	Анкета нужденного, реєстр тих хто отримав допомогу

Рис. 1.2. Перший рівень декомпозиції бізнес-процесу "Модуль компаній"

Внаслідок декомпозиції бізнес-процесу "Модуль компаній" були виділені наступні роботи:

додання нужденного;

формування лоту;

запуск лоту;

формування звітності.

Діаграма другого рівня декомпозиції бізнес-процесу "Створення лоту" наведена на рис. 1.3 та її опис наведений у табл. 1.3 [33].

Таблиця 1.3. Характеристика бізнес-процесу "Створення лоту"

Назва характеристики	Значення
Ім'я бізнес-процесу	Створення лоту
Основні учасники	Представник компанії з питань благодійності, адміністратор
Вхідна подія	Запит на створення лоту
Вхідні документи	Інформація для створення лоту
Вихідна подія	Створений лот, занесення інформації нужденного до реєстру отримавших допомоги
Вихідні документи	Створений лот, реєстр тих хто отримав допомогу

Рис. 1.3. Другий рівень декомпозиції бізнес-процесу "Створення лоту"

1.3 Аналіз існуючих програмних продуктів

У сучасному суспільстві люди завжди шукають пріоритети. В нашому випадку програмне забезпечення не являється винятком [27].

Відповідно до завдання на дипломне проектування та опису предметної області були розглянуті існуючі програмні продукти.

В процесі вивчення теми благодійності була розглянута велика кількість Інтернет джерел, але прототипів даної теми знайдено не було.

Порівняння проводилося з двома Інтернет благодійними фондами:

Інтернет благодійний фонд "Спасибо";

Інтернет благодійний фонд "Грачи прилетели".

Інтернет благодійний аукціон "Спасибо" має приємний і легкий для освоєння інтерфейс користувача [29]. Головна сторінка представлена на рис. 1.4.

Рис. 1.4. Головна сторінка сайту

Сайт надає змогу перегляду документів про благодійний фонд, які підтверджують те, що дане інтернет-джерело насправді існує і не є "липовим" (рис. 1.5). По завершенню збору коштів, на сайті з'являється фото з нужденним, в якому вказується, яку саме суму вдалося зібрати, де в котрий раз користувач підтверджує свої сподівання.

Рис. 1.5. Сторінка "Документи"

На сайті існує сторінка, яка надає змогу детального перегляду інформації про те, кому дана благодійна організація вже допомогла, та надає детальну інформацію про те, яку саме суму вносили в певний проміжок часу. Сторінка "Кому допомогли" представлена на рис. 1.6.

Рис. 1.6. Сторінка "Кому помогли"

Також варто виділити те, що сайт в розробці над новими проектами та надає можливість перегляду уже створених. Дані проекти направлені на отримання якомога більшої суми коштів для надання благодійної підтримки потребуючим людям, та направлена на збір пожертвувань шляхом проведення торгів та благодійних скриньок. Сторінка "Проекти" наведена на рис. 1.7.

Рис. 1.7. Сторінка "Проекти"

Ще одним аналогом інтернет благодійних сайтів був розглянутий програмний продукт "Грачи прилетели" [30]. Цей Інтернет благодійний фонд дуже сподобався оформленням та наповненням. Простота оформлення надає змогу користувачеві приємно та безперешкодно переглядати інформацію. Головна сторінка сайту наведена на рис. 1.8.

Сайт приємно вразив сторінкою "Ярмарки", яка представлена на рис. 1.9. Дана сторінка надає змогу перегляду так званих проектів які вже пройшли та будуть проходити в найближчий час.



Рис. 1.8. Головна сторінка сайту

Рис. 1.9. Сторінка "Ярмарки"

Даний програмний продукт також надає змогу звернення до on-line співробітників, які своєчасно допоможуть в питанні, що цікавить користувача. Сторінка "on-line підтримки" наведена на рис. 1.10.



Рис. 1.10. Сторінка "on-line підтримки"

Під час розгляду згаданих програмних продуктів були виділені переваги та недоліки обох сайтів (табл. 1.4).

Таблиця 1.4. Порівняльна характеристика програмних продуктів

Характеристика	Web-Сайт
	Спасибо	Грачи прилетели
Пошук по параметрам	+	+
Додавання нових спонсорів	-	-
Блокування / розблокування користувачів	-	-
Додавання, видалення, редагування проектів	+	+
Детальній перегляд руху коштів	+	+
Партнерські програми	+	-
Документи на підтвердження	+	-
Можливість зв'язку з оператором	-	+
Локалізація	-	+

В ході роботи над першим розділом була проаналізована предметна область розроблюваного модуля, були виявлені основні бізнес-процеси розроблюваної системи, а саме:

облік компаній;

розіграш лотів;

звіт з переведених коштів.

У зв'язку з цим, були побудовані діаграми бізнес-процесів у стандарті IDEF0, та проаналізований кожний крок отриманого бізнес-процесу системи.

Також були проаналізовані подібні модулі програмних продуктів благодійних Інтернет-аукціонів, а саме благодійний фонд "Спасибо" та програмний продукт "Грачи прилетели". В ході аналізу були виявлені сильні та слабкі сторони програмних продуктів, які були наведені у табл. 1.4, приведена порівняльна характеристика.

Виконана робота є основою для подальшого проектування програмного продукту, а саме для проектування варіантів використання та кінцевого бачення проекту.



2. Специфікація вимог до модуля "Облік компаній"

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

Розроблення розділу специфікація вимог до модулю ґрунтується на створенні специфіка вимог до системи. Розділ буде складатися з глосарію, варіантів використання, функціональних та нефункціональних вимог.

2.1 Глосарій

Глосарій проекту - це комплексний вступ в яку-небудь тему, опис основних термінів використаних в документації.

Глосарій проекту наведено у табл. 2.1.

Таблиця 2.1. Глосарій проекту

Термін	Опис терміну
1. Основні поняття та категорії предметної області та проекту
Модуль автоматизації	Система, яка контролює процес надання певній особі прав на виконання певних дій
Головне вікно модуля	Початкове вікно. Головне вікно бере основну увагу діям користувача в додатку
Лот	Група однорідних предметів або приз у розіграші лотерей, проведенні конкурсів, змагань, вікторин та тому подібне
Компанії	Виконавча дирекція програмного продукту, яка являється основним органом надання допомоги нужденним. Забезпечує матеріальну підтримку потребуючим допомоги
Нужденний	Особа, яка має потребу допомоги
2. Користувачі системи
Адміністратор	Адміністратор web-сайту стежить за працездатністю сервера (серверного устаткування і програм), на якому знаходиться web-сайт, несе відповідальність за мережеву безпеку
Користувач	Людина, яка займається звітністю та аналізом щодо потребуючих допомоги
Представник компанії	Являється однією з основних діючих осіб, які займаються створенням лотів для благодійного аукціону
Вхідні та вихідні документи
Дані нужденного	Персональні дані потребуючого допомоги
Дані компанії	Персональні дані компанії, яка являється організатором аукціону
Нормативні акти	Нормативно-правові акти що до проведення аукціонів
Звіт отримавших допомогу	Звіт, який містить персональні дані нужденних, які отримали допомогу та сума яку вони отримали
Заявки на отримання допомоги	Документ, який надає право на надання допомоги. Обов'язково заповнюється лицем, яке потребує допомоги
Реєстр отримавших допомогу	Звіт, який відображає роботу благодійного аукціону. Відображає інформацію нужденного, який отримав допомогу, дату початку та дату закінчення проведення розіграшу лоту, переможця розіграшу
Анкета нужденного	Документ, який створюється представником компанії з питань благодійності. Містить персональну інформацію потребуючого допомоги
Створений лот	Містить інформацію нужденного та інформацію компанії, яка надає послуги благодійності

2.2 Розроблення варіантів використання

2.2.1 Діаграма варіантів використання

Діаграма варіантів використання "Інтерфейс компаній", яка зображена на рис. 2.1 призначена для графічного відображення основних частин розроблюваного модулю та встановлення зв'язків, послідовностей варіантів використання. Під час проектування діаграми використання були визначені основні частини варіантів використання:

додання нужденного (забезпечує введення, редагування, видалення та перегляд даних нужденного);

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

створення нового лоту (забезпечує створення нового лоту, який запускається тільки після дозволу адміністратора сайту).

2.2.2 Специфікація варіантів використання

Даний розділ описує варіанти використання які проілюстровані на рис. 2.1. В табл. 2.2-2.3 приведений опис основних варіантів використання модуля "Інтерфейс компаній" [1]. Далі будуть представлені такі варіанти використання як: "Додання нужденного", "Перевірка потребуючого допомоги", "Створення нового лоту".

Таблиця 2.2. Варіанти використання "Додання нужденного"

Характеристика	Значення
Контекст використання	Робота над даними потребуючих допомоги
Дійові особи	Представник компанії з питань благодійності
Предумова	1. Представник компанії аутентифікований. 2. Представник має право на обробку персональних даних потребуючого допомоги. 3. База даних в момент опрацювання підключена.
Триггер	Представник компанії бажає ввести, переглянути чи редагувати дані про потребуючого допомоги
Сценарій	1. Перейти на головне вікно програми. 2. Обрати необхідний пункт меню
Постумова	1. Представник компанії отримує можливість обробки даних про нужденного. 2. Інакше стан системи не зміниться
Контекст використання	Робота над персональними даними потребуючих допомоги.
Предумова	1. Представник компанії аутентифікований. 2. Представник має право на обробку персональних даних потребуючого допомоги. 3. База даних в момент опрацювання підключена.
Дійові особи	Представник компанії з питань благодійності.
Триггер	Представник компанії бажає ввести, переглянути чи редагувати дані про потребуючого допомоги. Перевірка на наявність потрібних документів.
Сценарій	1. Перейти на головне вікно програми. 2. Обрати необхідний пункт меню.
Постумова	Представник компанії отримує можливість обробки даних про нужденного.

Таблиця 2.3. Варіанти використання "Створення нового лоту"

Характеристика	Значення
Контекст використання	Робота над даними нужденного
Дійові особи	Представник компанії з питань благодійності, Адміністратор сайту
Предумова	1. Представник компанії аутентифікований. 2. Представник має право на обробку персональних даних потребуючого допомоги. 3. База даних в момент опрацювання підключена. 4. Всі персональні дані відповідають дійсності та наявності
Триггер	Представник компанії бажає ввести, переглянути чи редагувати дані про потребуючого допомоги. Створити новий лот для нужденного та відправити запит на підтвердження адміністраторові
Сценарій	1. Перейти на головне вікно програми. 2. Обрати необхідний пункт меню. 3. Заповнити лот необхідною інформацією
Постумова	1. Представник компанії отримує можливість обробки даних про нужденного. 2. Отримання відповіді від адміністратора. 3. Інакше стан системи не зміниться

Рис. 2.1. Діаграма варіантів використання "Інтерфейс компаній"

2.3 Специфікація функціональних та нефункціональних вимог

Вимоги до програмного забезпечення - це сукупність тверджень щодо атрибутів, властивостей або якостей програмної системи, що підлягає реалізації. Створюються в процесі розробки вимог до програмного забезпечення, в результаті аналізу вимог. Існують функціональні та нефункціональні вимоги до системи [18].

Функціональні вимоги пояснюють, що повинно бути зроблено. Вони ідентифікують завдання або дії, які повинні бути виконані. Функціональні вимоги визначають дії, які система повинна бути здатною виконати, зв'язок входу / виходу в поведінці системи. Що стосується не функціональних вимог - це вимоги, які визначають критерії роботи системи в цілому, а не окремі сценарії поведінки. Нефункціональні вимоги визначають системні властивості такі як продуктивність, зручність супроводу, розширюваність, надійність.

Вимогами до програмного продукту являються властивості та якості програмного продукту, сукупність вимог щодо атрибутів. Специфікація функціональних вимог описує внутрішню роботу всієї системи та її поведінку під час використання. Нефункціональні вимоги відображають критерії роботи в цілому. На рис. 2.2 відображена головна форма списку нужденних.

Рис. 2.2. "Список нужденних"

2.3.1 Функціональні вимоги

Опис всіх функціональних вимог розроблюваного програмного продукту та список вимог атрибутів наведений у табл. 2.4 Додання нового нужденного зображено на рис. 2.3.

Рис. 2.3. "Додання нового нужденного"

Таблиця 2.4. Специфікація функціональних вимог

Ідентифікатор вимоги	Назва вимоги (варіанту використання)	Атрибути вимог
		Пріоритет	Трудність	Контакт
UC-01	Вхід до системи	Високий	Середня	Представник компанії з питань благодійності
UC-02	Робота з даними потребуючих допомоги	Високий	Висока	Представник компанії з питань благодійності
UC-03	Перегляд персональних даних потребуючого	Високий	Висока	Представник компанії з питань благодійності
UC-04	Введення даних потребуючого допомоги	Високий	Висока	Представник компанії з питань благодійності
UC-05	Редагування даних потребуючого допомоги	Високий	Середня	Представник компанії з питань благодійності
UC-06	Видалення даних потребуючого допомоги	Високий	Середня	Представник компанії з питань благодійності
UC-07	Збереження звіту нужденних	Високий	Висока	Представник компанії з питань благодійності
UC-08	Видалення звіту нужденних	Високий	Висока	Представник компанії з питань благодійності
UC-09	Перегляд звіту нужденних	Високий	Низька	Представник компанії з питань благодійності
UC-10	Друк звіту нужденного	Високий	Низька	Представник компанії з питань благодійності
UC-11	Експорт звіту нужденного	Високий	Висока	Представник компанії з питань благодійності
UC-12	Додання звіту нужденного	Високий	Висока	Представник компанії з питань благодійності
UC-13	Перевірка персональних даних потребуючого	Високий	Висока	Представник компанії з питань благодійності
UC-14	Створення лоту	Високий	Висока	Представник компанії з питань благодійності
UC-15	Редагування лоту	Високий	Висока	Представник компанії з питань благодійності
UC-16	Експорт даних лоту нужденного	Високий	Висока	Представник компанії з питань благодійності
UC-17	Перегляд звіту отримавши допомогу	Високий	Низька	Представник компанії з питань благодійності

2.3.2 Нефункціональні вимоги

Нефункціональні вимоги містять в собі всі вимоги, які не стосувалися фінальності проекту. Опис нефункціональних вимог детальніше наведений у табл. 2.5.

Таблиця 2.5. Специфікація нефункціональних вимог

Ідентифікатор вимоги	Назва вимоги (варіанту використання)	Атрибути вимог
		Пріоритет	Трудність	Контакт
1. Застосованість
АR-01	Запуск системи не більше 5 сек.	Рекомендований	Середня	Представник компанії з питань благодійності
АR-02	Зручність та функціональність інтерфейсу згідно стилю	Рекомендований	Середня	Представник компанії з питань благодійності
АR-03	Практичність має бути не гіршою, ніж системи зображені у документі концепції.	Рекомендований	Середня	Представник компанії з питань благодійності
АR-04	Підготовка користувача до використання даної системи не має перевищувати 20 хв.	Рекомендований	Низька	Представник компанії з питань благодійності
АR-05	Наповнення звіту виконується не довше 15 хвилин. Підвищення кваліфікації виконавця, забезпечує збільшення швидкості заповнення відповідної документації	Рекомендований	Середня	Представник компанії з питань благодійності
АR-06	Система застосовується відповідно з створеними системами документообігу, які налаштовані під цю систему.	Рекомендований	Середня	Представник компанії з питань благодійності
2. Надійність
RR-01	Під час входу до системи, для доступу суб'єкта необхідно здійснити його аутентифікацію та авторизацію	Рекомендований	Висока	Представник компанії з питань благодійності
RR-02	Аутентифікація здійснюється завдяки персонального пароля.	Рекомендований	Середня	Представник компанії з питань благодійності
RR-03	Безвідмовний час роботи повинен складати не затраченого часу, потрібного для заповнення даних одного об'єкту.	Рекомендований	Середня	Представник компанії з питань благодійності
3. Робочі характеристики
PR-01	Запуск системи не перевищує 10 секунд	Рекомендований	Низька	Представник компанії з питань благодійності
PR-02	Час затрачений на пошук даних повинен не перевищувати 10 секунд.	Рекомендований	Висока	Представник компанії з питань благодійності
PR-03	Одночасне використання 50 клієнтів не повинно приводити до зниження продуктивності системи	Рекомендований	Висока	Представник компанії з питань благодійності
4. Оперативна придатність
ОR-01	Система розрахована на використання замовника враховуючи специфіку підприємства	Рекомендований	Низька	Представник компанії з питань благодійності
ОR-02	Система розрахована на безперебійну роботу персонального комп'ютера.	Обов'язковий	Висока	Представник компанії з питань благодійності
ОR-03	Робота програми залежить від відповідних технічних характеристик обладнання.	Обов'язковий	Висока	Представник компанії з питань благодійності
5. Обмеження проекту
РR-01	Середовищем розробки являється Ruby on Rails	Обов'язковий	Висока	Представник компанії з питань благодійності
6. Вимоги щодо документації
DR-01	Повідомлення із попередженнями про помилки виводяться у відповідні вікна.	Рекомендований	Середня	Представник компанії з питань благодійності
DR-02	Довідка	Необов'язковий	Низька	Представник компанії з питань благодійності
7. Куповані частини
	Куповані частини не передбачені
8. Інтерфейс компанії
ІU-01	Оформлення вікон та повідомлення системи повинно бути єдиним та відповідати стандартові розробки інтерфейсів.	Рекомендований	Середня	Представник компанії з питань благодійності
ІU-02	Ведення бази даних здійснюється шляхом редагування, додання та видалення таблиць БД.	Обов'язковий	Середня	Представник компанії з питань благодійності
ІU-03	Редагування виконується завдяки відповідних форм (заповнення полів). Поля забезпечують легке та зручне введення відповідної інформації (випадаючі списки, радіо кнопки).	Обов'язковий	Середня	Представник компанії з питань благодійності
9. Програмний інтерфейс
ІS-01	Операційна система Linux	Необов'язковий	Низька	Представник компанії з питань благодійності
10. Вимога ліцензування продукту
LR-01	Розповсюдження програми здійснюється безкоштовно, за умови що замовник не висуне вимоги на ліцензування.	Рекомендовано	Середня	Представник компанії з питань благодійності
11. Застереження пов'язані з авторським правом
СR-01	Авторське право належить суб'єктові який розробив програму (програмісту).	обов'язковий	середня	Представник компанії з питань благодійності

Під час написання другого розділу було розроблено глосарій проекту, завдяки якому були описані основні терміни які використалися під час написання проектної документації. Також було розроблено діаграми варіантів використання, який наглядно відображає основні частини розроблюваного модулю, завдяки якій була розроблена специфікація варіантів використання. Діаграма варіантів використання лягла за основу детального написання варіантів використання, а саме написання функціональних та нефунк-ціональних вимог. Завдяки написанню функціональних та нефункціональних вимог буде краще протестований програмний продукт в цілому.

3. Проектні та технічні рішення

3.1 Математична постановка задачі

Для того, щоб розіграш лоту здійснився, необхідна одна з двох умов: кількість можливих білетів у розіграшу лоту набралась, або, якщо не виповнилась перша умова, настала дата розіграшу лоту. В кожному розіграші є гарантований переможець. Один користувач може поставити будь-яку кількість білетів, але не більше ніж кількість, яка залишилась до максимуму. Реалізація формули складається з декількох дій.

Крок перший. Дізнаємось, скільки відсотків припадає на кожен білет: Відсотки на 1 білет = 100 % поділити на кількість білетів, які зібралися до розіграшу. Крок другий. Для кожного з учасників виявимо інтервал. Інтервал одного учасника = кількість білетів кожного з учасників помножимо на Відсотки на 1 білет. Таким чином, ми отримали декілька чисел, які допоможуть побудувати головний інтервал. Головний інтервал будується наступним чином: точка відліку - 1 % далі береться результат 1 розрахунку інтервала одного з учасників -1, це число буде другою точкою на графіку, далі береться результат 2 розрахунку інтервала одного з учасників -1 це буде 3 точка, і таким чином ми працюємо, поки не опишемо всіх учасників і не дойдемо до 100 %. Далі ми отримали відрізок, від 1 до 100 %, який розбитий по секціям, кожній з секцій, відповідає певний користувач, чим більше білетів, тим більше процентних поінтів у користувача (тим більше ймовірність перемоги). Наступним кроком спеціальна програма генерує число, від 1 до 100. Останнім пунктом, нам залишається знайти це число на відрізку та ідентифікувати користувача-переможця.

3.2 Проектування структури бази даних

Створення бази даних слід починати з її проектування. У результаті проектування має бути визначена структура бази, тобто склад таблиць, їхня структура та логічні зв'язки [5].

Структура реляційної таблиці визначається складом стовпців, їхньою послідовністю, типом даних кожного стовпця та їхнім розміром, а також ключем таблиці. Процес проектування можна здійснювати двома підходами. За першого підходу спочатку визначають основні задачі, для розв'язання яких створюється база, та потреби цих задач у даних. За другого підходу визначають предметну область (сферу), здійснюють аналіз її даних і встановлюють типові об'єкти предметної області. Найбільш раціональним підходом проектування бази даних є поєднання обох підходів.

3.2.1 Концептуальне інфологічне проектування

Інфологічний рівень являє собою інформаційно-логічну модель (ІЛМ) предметної області, в якій виключена надмірність даних і відображені інформаційні особливості об'єкту управління, без урахування особливостей і специфіки конкретної СУБД [6]. Мета інфологічного проектування - створити структуровану інформаційну модель ПО, для якої розроблятиметься БД.

Словник даних - центральне сховище інформації про дані, такий як значення, взаємозв'язку з іншими даними, їх джерело, застосування і формат.

При створенні кожної з таблиць, додатково створюється 2 поля, які називаються created_at та updated_at. Також, не беручи до уваги технології, автоматично в кожній таблиці створюється поле id. Ці 3 поля будуть описані в табл. 3.1 один раз, так як вони мають завжди однаковий формат. Словник даних наведений у табл. 3.1.

Таблиця 3.1. Словник даних

№ п/п	Найменування елемента	Тип і довжина	Призначення елемента
1	id	integer	Унікальний номер
2	created_at	DateTime	Час створення будь-якого запису в таблиці
3	updated_at	DateTime	Час оновлення будь-якого запису в таблиці
4	user_id	integer	Унікальний ідентифікатор користувача
5	bill_number	varchar	Номер рахунку компанії
6	document_path	varchar	Шлях до файлу документу
7	title(company_helps)	varchar	Опис назви нужденного
8	description(company)	text	Описання подробиць про компанію
9	active_help	boolean	Статус нужденного
10	telephone_number	varchar	Номер телефону
11	country_name	varchar	Назва країни
12	company_help_id	integer	Унікальний номер нужденного
13	lot_name	Varchar	Назва лота
14	max_tickets	Integer	Максимальна кількість білетів, які можна поставити на 1 лот
15	lot_type	Boolean	Тип лоту - перезапускаємий чи ні
16	lot_status	Boolean	Статус лоту - активний чи ні
17	Present	Varchar	Опис подарунку переможцю за лот
18	winner_id	Integer	Унікальний номер користувача, який здобув перемогу у розіграші лоту
19	Versions	Integer	Номер версії міграції
20	lot_id	Integer	Унікальний номер лоту
21	ticket_amount	Integer	Кількість білетів які поставлені на 1 лот
22	nick_name	Varchar	Назва користувача в середовищі системи
23	Company	Boolean	Компанія чи користувач
24	first_name	Varchar	Назва користувача системи
25	middle_name	Varchar	По-батькові користувача
26	last_name	Varchar	Прізвище користувача
27	Approved	Boolean	Підтверджений, чи ні
28	date_of_birth	Date	Дата народження користувача
29	about_me	Text	Опис додаткової інформації про користувача
30	ticket_amount	integer	Кількість білетів користувача
31	Admin	Boolean	Чи має користувач права адміністратору
32	country_id	Integer	Унікальний номер коду країни
33	company_name	Varchar	Назва компанії
34	Main_address	Varchar	Головна адреса компанії
35	Email	Varchar	Email адреса користувача
36	encrypted_password	Varchar	Зашифрований пароль користувача
37	sign_in_count	Integer	Кількість успішних авторизацій користувача

3.2.2 Проектування глобальної даталогічної моделі даних

Структура логічної моделі бази даних відображає елементи, які в ній знаходяться. На рис. 3.1 відображена структура логічної моделі даних. За даною логічною схемою побудована фізична модель (рис. 3.2), в якій враховані такі особливості СКБД, як припустимі типи і найменування полів.

Рис. 3.1. Структура логічної моделі даних

3.2.3 Проектування фізичної моделі даних бази даних та її реалізація

Проектування фізичної моделі даних включає опис розробки моделі да-них на фізичному рівні як результат генерації команд SQL-скрипту по створенню основних об'єктів зберігання в БД таких як таблиці, подання, ключі.

Структура фізичної моделі даних відображена на рис. 3.2.

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

Рис. 3.1. Структура фізичної моделі даних

3.3 Розроблення архітектури програмної системи

3.3.1 UML діаграма діяльності варіантів використання

Задача сайту для медичної лабораторії містить у собі рішення покращення діяльності лабораторії. За допомогою діаграм діяльності варіантів використання можна детально ознайомитись з процесом роботи та діями що проходять всередині цих процесів.

Загальна діаграма діяльності предметної області наведена у дод. А.

Діаграма діяльності варіанту використання "Додавання благодійної компанії" наведена на рис. 3.3, містить події, при виконанні яких адміністратор перегляне заявку від компанії та підтвердить її.

На рис. 3.4 наведена діаграма діяльності варіанту використання "Додавання нужденного в допомозі", яка містить події, при виконанні яких адміністратор додає в базу нужденного в допомозі.

На рис. 3.5 наведена діаграма діяльності варіанту використання "Додавання лоту", яка містить події, при виконанні яких лот на розіграш.

Рис. 3.3. Діаграма діяльності варіанту використання "Додавання благодійної компанії"

Рис. 3.4. Діаграма діяльності варіанту використання "Додавання нужденного в допомозі"



Рис. 3.5. Діаграма діяльності варіанту використання "Додавання лоту"

3.3.2 UML діаграми класів

Мета моделювання документів - описати атрибути документів, їх типи, значення, правила формування для проектування інтерфейсу системи, проектування бази даних системи; формування альбому вихідних форм системи [12].

Діаграма класів зображена на рис. 3.6.



Рис. 3.6. Діаграма класів

3.4 Тестування програмної системи

Тестування програмної системи - техніка контролю якості, що перевіряє відповідність між реальною і очікуваною поведінкою програми завдяки кінцевому набору тестів, які обираються певним чином [3]. Тестування, як процес своєчасного виявлення помилок та дефектів, не може повністю забезпечити коректність програмного забезпечення. Воно тільки порівнює стан і поведінку продукту зі специфікацією.

Для проведення повнофункціонального тестування розділимо web-додаток на наступні складові:

тестування навігації;

тестування сторінок сайту;

тестування пошуку інформації;

тестування роботи он-лайн консультації;

тестування отримання результатів розіграшу лоту;

тестування наповнення сайту контентом.

Мета тестування - перевірка коректної роботи та функціонування.

Розглянемо тестування навантаження, тестування властивостей, регресійне тестування, тестування графічного інтерфейсу користувача.

3.4.1 Тестування навантаження

Основна мета навантажувального тестування - вивести систему з ладу, визначити ті умови, при яких вона не зможе далі нормально працювати. Це тестування було пройдено, допустивши до роботи чотирьох користувачів сайту одночасно. Тестування навантаження припускає також перевірку роботи про-грами з максимальним обсягом даних, для виявлення помилок та покращання роботи системи.

3.4.2 Тестування властивостей

Метою є працездатність програми на різних комбінаціях конфігурацій клієнт/сервер. Тестування властивостей, припускає функціональне і негативне тестування (спроба виконання операцій і введення даних, не передбачених розробниками).

3.4.3 Регресійне тестування

Для регресійного тестування програмного продукту пропонується здійснювати виправлення помилок у міру їх виявлення.

3.4.4 Тестування графічного інтерфейсу користувача

При тестуванні графічного інтерфейсу сайту "Благодійний аукціон" використовується наступний підхід:

усі дії з тестування виконуються в ручному режимі;

усі дефекти відстежуються і усуваються за допомогою корпоративної системи відстеження дефектів.

Метою тестування графічного інтерфейсу користувача є знаходження недоробок в графічному інтерфейсі в ході проведення різних оцінок після за-вершення написання проекту [9]. На підставі отриманих даних інтерфейс повинен бути розроблений так, щоб цільова аудиторія продукту мала можливість найбільш ефективно працювати з фінальною версією сайту. Як приклад тестування інте-рфейсу нижче надані скріншоти сайту (рис. 3.6-3.10).

Рис. 3.6. Тестування графічного інтерфейсу - Головна сторінка сайту

Рис. 3.7. Тестування графічного інтерфейсу - Авторизація адміністратора



Рис. 3.8. Тестування графічного інтерфейсу - Підтвердження заявки на додавання благодійної компанії

Рис. 3.9. Тестування графічного інтерфейсу - Додавання лоту на розіграш



Рис. 3.10. Тестування графічного інтерфейсу - Вікно перегляду лотів

Базове тестування, тестування валідації та тестування юзабіліті наведено у дод. Б (табл. Б.1 - Б.3).

3.5 Розгортання програмного продукту

Для розгортання програмного продукту, а саме web-сайту, необхідно мати сервер де буде розташовуватись сайт. Щоб web-сервіс коректно та справно функціонував потрібен сервер з підтримкою MySQL.

Для клієнтської частини існують наступні мінімальні вимоги:

процесор AMD Athlon 1000 Hz;

монітор користувача з роздільною здатністю 1024 х 768 dpi;

HDD, 40 ГБ;

оперативний запам'ятовуючий пристрій розміром 256 Мб;

комп'ютерна клавіатура зі стандартною кількістю клавіш, та комп'ютерна миша;

операційна система Windows XP/Windows 7/Windows 8;

безперебійний зв'язок з мережею Iнтернет, мінімум 256 КБ/сек;

інтернет-браузер з підтримкою XHTML та CSS не нижче 2 версії;

програмне забезпечення Microsoft Office 2003 та вище;

встановлений принтер.

В розділі "Проектні та технічні рішення" була описана логічна постановка задачі, у вигляді інструкції до сайту. Потім була розглянута робота з базою даних сайту, починаю з проектування. У результаті проектування була визначена структура бази, тобто склад таблиць, їхня структура та логічні зв'язки. Описаний словник даних (табл. 3.1) та приведена логічна і фізична структура (рис. 3.1-3.2). Логічна модель даних відображає існуючі сутності та зв'язки між ними, а фізична модель відображає розроблену базу даних у конкретній СУБД.

Потім була побудована діаграма діяльності варіантів використання та загальна (дод. А).

Завершальний етап розділу і розробки додатку - тестування. Розглянули тестування навантаження, тестування властивостей, регресійне тестування та тестування графічного інтерфейсу користувача.

Підсумком роботи цього розділу став повнофункціональний програмний продукт, який виконує всі заявлені функції і відповідає заявленим вимогам.



4. Охорона праці

4.1 Аналіз санітарно-гігієнічних умов праці у приміщенні

Умови праці - це складне об'єктивне суспільне явище, що формується в процесі праці під впливом взаємозв'язаних чинників соціально-економічного, технико-організаційного і природно-природного характеру і впливає на здоров'я та працездатність людини, ефективність праці і інші результати виробництва [2; 10].

Санітарно-гігієнічні умови формуються під впливом на людину навколишнього середовища (шкідливі хімічні речовини, запорошена повітря, вібрація, освітлення, рівень шуму, інфразвук, ультразвук, електромагнітне поле, лазерне, іонізуюче, ультрафіолетове випромінювання, мікроклімат, мікроорганізми, біологічні чинники). Приведення цих чинників у відповідність з сучасними нормами, нормативами і стандартами є передумовою нормальної працездатності людини.

Робота по поліпшенню умов праці припускає в першу чергу вдосконалення техніки, технології і фізико-хімічних властивостей сировини, а також подальше вдосконалення виробничих процесів з урахуванням комплексу санітарних норм, стандартів і вимог [7; 11].

Загальна площа приміщення складає 24 м². Висота приміщення 3 м, об'єм приміщення 72 м³. Відповідно зі стандартом найменше допустиме значення виробничого приміщення складає: площі - 6,0 м² та об'єму - 20 м ³ [3], з чого можна зробити висновки, що приміщення відповідає стандарту. Стіни приміщення відділу мають шпалери світло-зеленого кольору, білу стелю (натяжні стелі), підлога вкрита ламінатом коричневого кольору. Стіл та шафа робочого приміщення мають світло-коричневий колір (ДСП).

Санітарно-побутові приміщення в будівлі розташовані відповідно до нормативних вимог. В кімнатах проводиться прибирання раз на день, з ранку [20]. Значення параметрів, які характеризують санітарно-гігієнічні умови праці в приміщенні наведені в табл. 4.1.

Таблиця 4.1. Параметри, які характеризують санітарно-гігієнічні умови праці в приміщенні

Параметри	Фактичне значення	Норматив по ДНАОП або ДСТУ	Відповідність параметрів нормі ДНАОП або ДСТУ
Температура повітря в приміщені, °С в холодний період	21-24	21-25	відповідає
Відносна вологість повітря, %	40-50	40-60	відповідає
Шум, дБА	50-60	50-65	відповідає

Зважаючи на дані табл. 4.1, можна сказати, що санітарно-гігієнічні умови праці в приміщенні відповідають нормативам.

4.2 Природне освітлення

Організація раціонального освітлення робочих місць - одне з основних питань охорони праці. При незадовільному освітленні різко знижується продуктивність праці, можливі нещасні випадки, швидка стомлюваність і т. п. Правильне освітлення приміщення підвищує продуктивність праці. Важливо, щоб співробітники під час робочого дня, проведеного за комп'ютерними моніторами, почували себе максимально комфортно [18].

Але слід зауважити, що природне світло характеризується тим, що створювана їм освітленість змінюється в надзвичайно широких межах залежно від часу дня, пори року, погодних умов. Природне освітлення здійснюється падінням прямих променів сонця через 3 вікна, площа яких становить 3,22 м ² (ширина - 1,4 м, висота - 2,3 м).

Достатність природного освітлення визначається за формулою (4.1) [23]:

(4.1)

де, S_вікон - площа вікон, м², S_{підлоги} - площа підлоги, м².

S_вікон = 3,223=9,66 (м²), S_{підлоги} = 24 (м²).

.

Коефіцієнт природного освітлення даного приміщення відповідає значенню норми [24].

4.3 Штучне освітлення

Правилами проектування для загального освітлення згідно з ДБН В. 2.5-28-2006 [28]слід використовувати, як правило, розрядні джерела світла, віддаючи перевагу за однакової потужності джерелам світла з найбільшою світловою віддачою і строком служби. Використання ламп розжарювання для загального освітлення допускається тільки у випадках неможливості або техніко-економічної недоцільності використання розрядних ламп. Застосування ксенонових ламп у приміщеннях не дозволяється.

4.4 Кондиціювання

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

Головною особливістю систем кондиціювання є те, що вони забезпечують обробку повітря та задовольняють найвищі вимоги до параметрів повітряного середовища закритих приміщень. При цьому стан повітряного середовища приміщення перестає бути залежним від параметрів зовнішнього (атмосферного) повітря [22].

Для того щоб отримати більш точну оцінку охолоджувальної потужності кондиціонера необхідно розраховувати всі тепловиділення, які надходять в приміщення, за такою формулою (4.2) [22]:

(Вт), (4.2)

де Q_заг - загальні тепловиділення в приміщення, Вт;

Q₁ - надходження тепла в приміщення від стін, підлоги, стелі й вікон, Вт;

Q₂ - надходження тепла в приміщення від людей, Вт;

Q₃ - надходження тепла в приміщення від обладнання, Вт.

Надходження тепла в приміщення від стін, підлоги, стелі й вікон можна визначити за такою формулою (4.3) [22]:

(Вт), (4.3)

де V - об'єм приміщення, м ³;

q - коефіцієнт, який має значення, у випадку південної орієнтації вікон - 40 Вт/м ³.

Надходження тепла в приміщення від людей можна визначити за такою формулою (4.4) [22]:

(Вт), (4.4)

де - кількість людей, які постійно працюють у приміщенні;

W - енерговитрати людини залежно від категорії виконуваних робіт.

Надходження тепла в приміщення від обладнання можна визначити за формулою (4.5) [22]:

(Вт), (4.5)

де N - потужність одиниці обладнання, Вт (N = 150 Вт для комп'ютера, N = 50 Вт для принтера, ксерокса, сканера і т. ін.);

- кількість одиниць обладнання, шт.

Отже, (Вт).

На підставі одержаного значення Q_заг обираємо близьку за потужністю модель кондиціонера зі стандартного ряду. Причому, якщо значення Q_заг не точно відповідає величинам, зазначеним у стандартному ряді, то в цьому випадку необхідно значення Q_заг округлити в більшу сторону до найближчої величини, наведеної в стандартному ряді.

Стандартний ряд місцевих кондиціонерів за охолоджувальною потужністю: 2,0 кВт; 2,5кВт; 3,5 кВт; 5,0 кВт; 7,0 кВт.

Робоче приміщення має два кондиціонери фірми Bosch, з потужністю 8 кВт. Можна зробити висновок, що кондиціонування в приміщенні відноситься до норми.

4.5 Пожежна безпека

Пожежна безпека - стан об'єкта, при якому з регламентованою ймовірністю виключається можливість виникнення та розвиток пожежі і впливу на людей її небезпечних факторів, а також забезпечується захист матеріальних цінностей. Причинами пожеж та вибухів на підприємстві є порушення правил і норм пожежної безпеки, невиконання "Кодексу цивільного захисту" [14]. Правила пожежної безпеки в Україні є обов'язковими для виконання всіма центральними і місцевими органами виконавчої влади, органами місцевого самоврядування, підприємствами, установами, організаціями (незалежно від виду їх діяльності та форм власності), посадовими особами та громадянами. Правила встановлюють загальні вимоги з пожежної безпеки, чинність яких поширюється на підприємства, установи, організації, а також житлові будинки, що експлуатуються, будуються, реконструюються, технічно переоснащуються і розширюються, за винятком підземних споруд та транспортних засобів, вимоги до яких визначаються у спеціальних нормативних документах.

Приміщення відноситься до категорії В [34].

Система протипожежної безпеки відділу складає наступний комплекс організаційних і технічних засобів, спрямованих на запобігання впливу на людей небезпечних факторів пожежі та обмеження матеріальних збитків від нього: підтримка нормальної температури, вологості та тиску середовища; ізоляція пожежонебезпечного обладнання та підтримка його в нормальному стані; застосування засобів пожежогасіння (індивідуальні засоби пожежогасіння, до яких відносяться порошковий та вуглекислий вогнегасники; наявність пожежного крану, пожежного щиту з піском, лопатою, відром, сокирою); проведення інструктажів з пожежної безпеки; наявність системи протидимної безпеки. Виходячи з цього відділ екології має достатній рівень для попередження пожежі [21].

В приміщенні знаходяться 2 вогнегасника порошкового типу(ОП), на поверсі, де розташовано приміщення знаходиться пожежний кран, також є схема евакуації.

4.6 Психологічна безпека

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