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

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык украинский
Дата добавления 05.07.2015
Размер файла 184,5 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на 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


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.