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

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

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

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

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

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

2014

Зміст

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

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

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

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

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

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

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

Висновки

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

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

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

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

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

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

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

E = ab x (KLOC )bb ,

D = cb x Edb ,

де E - трудовитрати на проект (людино-місяці);

KLOC - кількість тисяч рядків коду;

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

D - час розробки у календарних місяцях.

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

Таблиця 1

Тип проекту	аb	bb	cb	db
Organic	2.4	1.05	2.5	0.38
Semi-detached	3.0	1.12	2.5	0.35
Embedded	3.6	1.20	2.5	0.32

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

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

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

Прогнозований обсяг 36 тис. рядків коду дає можливість скористатися даними проекту типу «Semi-detached». Тоді значення E та D становитимуть:

E = 3,0 x (36)1,12 = 166,03 люд.-міс.;

D = 2,5 x (166,0275)0,35 = 14,96 міс.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.1 Первинний візит.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПОШУКОВЕЦЬ
АТРИБУТИ КЛАСУ
Назва	Тип	Призначення
Код	integer	Унікальний номер запису в базі
Ім'я	string	Ім'я пошуковця
Спеціальність	string	Спеціальність згідно класифікатора
Стаж	integer	Стаж праці згідно трудової книжки
Освіта	string	Освіта (вища, середня)
ОПЕРАЦІЇ КЛАСУ
Назва	Вхідні параметри	Призначення
Додати	Дані згідно реєстраційної форми	Реєстрація нового пошуковця
Видалити	Код пошуковця	Видалення пошуковця, що більше не потребує послуг
Редагувати	Код пошуковця	Зміна реєстраційних даних пошуковця

РОБОТОДАВЕЦЬ
АТРИБУТИ КЛАСУ
Назва	Тип	Призначення
Код	integer	Унікальний номер запису в базі
Ім'я	string	Найменування роботодавця
ОПЕРАЦІЯ КЛАСУ
Назва	Вхідні параметри	Призначення
Додати	Дані згідно реєстраційної форми	Реєстрація нового роботодавця
Видалити	Код роботодавця	Видалення роботодавця, що більше не потребує послуг
Редагувати	Код роботодавця	Зміна реєстраційних даних роботодавця

ІНСПЕКТОР
АТРИБУТИ КЛАСУ
Назва	Тип	Призначення
Код	integer	Унікальний номер запису в базі
Ім'я	string	Ідентифікатор інспектору
Код пошуковця	integer	Ведення бази даних пошуковців
Код вакансії	integer	Доступ до бази даних вакансій
ОПЕРАЦІЯ КЛАСУ
Назва	Вхідні параметри	Призначення
Додати	Код інспектора	Реєстрація нового інспектора
Видалити	Код інспектора	Видалення даних інспектора, що не працює
Редагувати	Код інспектора	Редагування даних діючого інспектора

АДМІНІСТРАТОР
АТРИБУТИ КЛАСУ
Назва	Тип	Призначення
інспектора	integer	Унікальний номер запису в базі
Ім'я	string	Ідентифікатор адиіністратора
Код роботодавця	integer	Ведення бази даних роботодавців
Код вакансії	integer	Ведення бази даних вакансій
ОПЕРАЦІЯ КЛАСУ
Назва	Вхідні параметри	Призначення
Додати	Код адміністратора	Реєстрація нового адміністратора
Видалити	Код адміністратора	Видалення даних адміністратора, що не працює
Редагувати	Код адміністратора	Редагування даних діючого адміністратора

ВАКАНСІЯ
Назва	Тип	Призначення
Код	integer	Унікальний номер запису в базі
Ім'я	string	Найменування вакансії
Спеціальність	string	Критерії пошуків відповідності вакансії
Стаж	integer
Освіта	string
ОПЕРАЦІЯ КЛАСУ
Назва	Вхідні параметри	Призначення
Додати	Код вакансії	Реєстрація нової вакансії
Видалити	Код вакансії	Видалення зайнятої вакансії
Редагувати	Код вакансії	Редагування існуючої вакансії

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

Размещено на Allbest.ru