Автоматизована система бюро працевлаштування

Автоматизована система бюро працевлаштування

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

Курсова робота

з дисципліни «Інженерія програмного забезпечення»

на тему: «Автоматизована система бюро працевлаштування»

Зміст

Вхідні данні проекту

I. Планування проекту

II. Специфікація програмного забезпечення

III. Проектування програмного забезпечення

III.1 Проектування статичних аспектів програмного забезпечення

III.2 Проектування поведінки програмного забезпечення

III.3 Проектування архітектури програмного забезпечення

Висновки

Список літератури

Вхідні данні проекту

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

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

Ця робота пов’язана з обробкою великих масивів даних та вимагає точності та своєчасності в процесі підготовки та користування ними. Щоб забезпечити виконання означених вимог пропонується автоматизувати процедури функціонування бюро працевлаштування. Для цього буде створена інформаційна система, що буде складатися з бази даних підприємств та існуючих вакансій, бази даних здобувачів та пошукових запитів. База даних підприємств повинні містити контактну інформацію, опис існуючих вакансій та вимоги до потенційних здобувачів. Вдповідно база даних здобувачів повинна мати окрім контактів здобувача інформацію про освіту, попередні місця роботи та побажання до майбутнього працевлаштування.

.       
ПЛАНУВАННЯ ПРОЕКТУ

Оцінюємо трудовитрати на проект методом COCOMO за формулами:

= ab x (KLOC )bb ,= cb x Edb ,

де E - трудовитрати на проект (людино-місяці);- кількість тисяч рядків коду;, bb, cb та db - коефіцієнти, які обираються залежно від типу проекту (табл.1);- час розробки у календарних місяцях.

автоматизований працевлаштування програмний забезпечення

Таблиця 1

Тип «Organic» являє собою відносно невеликий (до 25 тис. рядків коду) та простий проект, який виконується невеликою командою.

Тип «Semi-detached» являє собою середній за розміром (до 75 тис. рядків коду) та складністю проект, в якому команда має змішаний рівень досвіду і відносно жорсткі вимоги.

Тип «Embedded» являє собою проект, який виконується в умовах жорстких технічних, програмних та експлуатаційних обмежень.

Прогнозований обсяг 36 тис. рядків коду дає можливість скористатися даними проекту типу «Semi-detached». Тоді значення E та D становитимуть:= 3,0 x (36)1,12 = 166,03 люд.-міс.;= 2,5 x (166,0275)0,35 = 14,96 міс.

Виходячи з цих значень, визначаємо, що середня кількість розробників дорівнює 11 особам. Повна собівартість розробки та закупівля всього потрібного обладнання (розрахована з допомогою СОСОМО Calkulator) складає - 1 824 282 гривень.

II. СПЕЦИФІКАЦІЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Малюнок II.1 - Діаграма прецедентів

1. Прецедент - Авторизація відвідувача

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

1.2. Суб’єкт - Відвідувач

1.3. Передумова. Відвідувач відкриває форму ідентифікації.

.4. Основний потік

.4.1. Відвідувач вводить свої дані.

.4.2. Якщо інформація введена правильно та повністю система видає реєстраційну форму ідентифікації відвідувача.

.4.2.1 Якщо результатом є ідентифікація відвідувача як пошуковця, система печатає чек-лист з номером відповідного інспектора та час відвідування.

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

.5. Альтернативные потоки

А1. Якщо інформації про відвідувача в системі немає, видається запит на первинну реєстрацію та форма, яка має бути заповнена первинними даними про відвідувача. Прецедент продовжується.

А2. Наявність відмітки про недостовірність даних. Якщо в процесі перевірки первинних даних, або в період існування реєстрації виявлений факт їх недостовірності чи зміни - дані повинні бути виправлені\відновлені. Прецедент продовжується.

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

3.2. Прецедент - Спілкування з інспектором

.1. Короткий опис. Інспектор перевіряє статус відвідувача - первинний візит чи плановий.

2.2. Суб’єкт - Інспектор.

2.3. Передумова. Інспектор відкриває форму ідентифікації відвідувача.

.4. Основний потік

.4.1.1 Заповнення форми даними: стать, вік, навчальний заклад, фах, знання та навички, додаткова інформація. Якщо інформація введена правильно та повністю система видає інспектору реєстраційну форму ідентифікації відвідувача.

.4.2. Черговий візит.

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

.4.2.2 Пошук та надання направлень на існуючі вакансії за фахом пошуковця.

.5. Альтернативні потоки

А1. Якщо пошуковця влаштовує попередньо видана вакансія, він знімається з реєстрації та його акаунт закривається.

А2. Перевірка графіку професійних навчать та інших заходів. Видача пошуковцю направлення на відповідний захід.

.6. Постумови. Виконується запис даних до журналу подій.

3. Прецедент - Спілкування з адміністратором

.1. Короткий опис. Адміністратор перевіряє статус відвідувача - новий роботодавець чи вже зареєстрований.

3.2. Суб’єкт - Адміністратор.

3.3. Передумова. Адміністратор відкриває форму ідентифікації відвідувача.

.4. Основний потік

.4.1 Реєстрація нового роботодавця.

.4.1.1 Заповнення форми даними: код підприємства, повна назва, скорочена назва, тип власності, адреса, контактні телефони, электронна адреса, вакантні посади, вимоги до вакансії. Якщо інформація введена правильно та повністю система видає адміністратору підтвердження у реєстрації нового роботодавця.

.4.2. Зміна списку наявних вакансій.

.4.2.1 Видалення закритих вакансій.

.4.2.2 Додавання нових вакансій.

.5. Альтернативные потоки

А1. Роботодавець вносить доповнення та(або) уточнення до існуючих вакансій.

.6.Постумови. Виконується запис даних до журналу подій.

III.    
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

.1 Проектування статичних аспектів програмного забезпечення

Малюнок III.1.1 Діаграма класів

III.2 Проектування поведінки програмного забезпечення

Малюнок III.2.1 Діаграма діяльності

Малюнок III.2.1 Діаграма послідовностей

III.3 Проектування архітектури програмного забезпечення

Малюнок III.2.2 Діаграма компонентів

ВИСНОВКИ

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

СПИСОК ЛІТЕРАТУРИ

1.      Леоненков. Самоучитель UML

2.      Курс лекцій по діаграмам UML

<http://khpi-iip.mipk.kharkiv.edu/library/case/leon/>

3.      Станкевич І.В. Класифікація діаграм UML