Фундаментальні базові процеси та моделі розроблення ПЗ

 

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

1. Аналіз користувача вимог

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

2. Вироблення пропозицій щодо реалізації

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

3. Технічне проектування

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

4. Програмування й налагодження.

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

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

 

Методологія розробки програмного забезпечення

1. Мінімізація ризиків

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

2. Реакція на зміни

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

3. Особиста бесіда, як основне джерело інформації

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

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

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

· каскадна модель;

· спіральна модель;

· еволюційна модель.

Каскадна модель

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

Рис. 2.1 Каскадна модель ЖЦ програмних систем

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

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

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

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

Переваги реалізації системи за допомогою каскадної моделі такі:

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

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

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

Спіральна модель

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

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

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

Ризик у даному випадку являє собою ситуації чи можливі випадки, що можуть стати на заваді проекту при досягненні ним певної мети (рис. 2.2.).

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

проходить значну кількість стадій, на кожній з яких, по-перше, відбувається

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

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

абсолютну величину відстані між кожною точкою на спіралі та точкою перетину осей на діаграмі.

Рис.2.2 Спіральна модель ЖЦ розробки програмних систем

Еволюційна модель

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

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

Рис.2.3 Еволюційного модель ЖЦ розробки програмних систем

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

Моделювання системи

 

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

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

Така діаграма явно демонструє функції, розробленого мною проекту модуля «Облік персоналу» для автоматизованої інформаційної системи «Управління персоналом корпорації». Контекстна та декомпозована діаграма зображені на рис.2.4 та рис.2.5.

Рис 2.4 Контекстна діаграма

Рис 2.5 Декомпозована діаграма

 

2.2.2. Діаграми варіантів використання. Діаграма варіантів використання (Use-Cases Diagram) - це UML діаграма за допомогою якої в графічному вигляді можна зобразити вимоги до розроблюваної системі. Діаграма варіантів використання - це вихідна концептуальна модель проектованої системи, вона не описує внутрішній устрій системи.

Діаграми варіантів використання призначені для:

- Визначення спільного кордону функціональності проектованої системи;

- Сформулювати загальні вимоги до функціонального поведінки проектованої системи

- Розробка вихідної концептуальної моделі системи;

- Створення основи для виконання аналізу, проектування, розробки і тестування.

Діаграма варіантів використання складається з ряду елементів. Основними елементами є: варіанти використання або прецедент (use case), актор або дійова особа (actor) і відносини між акторами і варіантами використання (relationship).

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

Рис 2.6 Варіанти використання керівником проекту модуля «Облік персоналу».

Рис 2.7 Варіанти використання персоналом проекту модуля «Облік персоналу».

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

Фактично даний тип діаграм може використатися й для відбиття станів модельованого об'єкта, однак, основне призначення діаграми активності (аctіvіty dіagram) у тому, щоб відбивати бізнес-процеси об'єкта. Цей тип діаграм дозволяє показати не тільки послідовність процесів, але й розгалуження й навіть синхронізацію процесів. Він дозволяє проектувати алгоритми поводження об'єктів будь-якої складності.

У контексті мови UML діяльність (actіvіty) являє собою сукупність окремих обчислень, виконуваних автоматом, що приводять до деякого результату або дії (actіon). На діаграмі діяльності відображається логіка й послідовність переходів від однієї діяльності до іншої, а увага аналітика фокусується на результатах. Результат діяльності може привести до зміни стану системи або поверненню деякого значення.

Рис.2.8 Блок-схема роботи проекту модуля «Облік персоналу».

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

Існує два види діаграм взаємодії: діаграми послідовності (sequence dіagrams) і кооперативні, або співробітництва (collaboratіon dіagrams). Діаграми послідовності визначають тимчасову послідовність переданих повідомлень, порядок, вид і тип повідомлення, що відбуваються в рамках варіанта використання.

На діаграмі послідовності взаємодія зображується у вигляді двовимірної схеми: вертикальне (час) і горизонтальне (об'єкти, що беруть участь у взаємодії). Істотна тільки послідовність повідомлень, однак тимчасова вісь може служити реальною метрикою виміру активності об'єкта. Прямокутники на вертикальних лініях показують "час життя" об'єкта. Лінії зі стрілками й написами назв методів означають виклик методу в об'єкта.

Рис.2.9 Діаграма взаємодії персоналу та керівника за допомогою проекту модуля «Облік персоналу».

 

2.2.5 Модель бази даних. Модель сутність-зв'язок (ER-модель) (англ. entity-relationship model, ERM) – модель даних, що дозволяє описувати концептуальні схеми предметної області.

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

Під час проектування баз даних відбувається перетворення ER-моделі в конкретну схему бази даних на основі вибраної моделі даних (реляційної, об'єктної, мережевий або ін.)

ER-модель являє собою формальну конструкцію, яка сама по собі не наказує ніяких графічних засобів її візуалізації. У якості стандартної графічної нотації, за допомогою якої можна візуалізувати ER-модель, була запропонована діаграма сутність-зв'язок (ER-діаграма) (англ. entity-relationship diagram, ERD).

Рис.2.10 Модель ЕR- діаграм

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

Побудова схеми бази даних

У СУБД Access процес створення реляційної бази даних включає створення схеми даних. Схема даних наочно відображає таблиці та зв'язки між ними, а також забезпечує використання зв'язків при обробці даних. В схемі даних встановлюються параметри забезпечення цілісності зв'язків у базі даних.

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

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

Рис.2.11 Схема даних

 

Розробка інтерфейсу

 

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

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

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

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

 

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

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

- зручність і простота роботи – інтерфейс повинен бути інтуїтивно зрозумілим, бажано, щоб всі дії легко запам'ятовувалися і не вимагали утомливих процедур: виконання додаткових команд, зайвих натискань на кнопки, виклику проміжних діалогових вікон;

- зовнішній дизайн не повинен стомлювати зір, він повинен бути розрахований на тривалу роботу користувача з програмою протягом дня;

- неперевантаженість форм – форми повинні бути оптимально завантажені елементами управління; при необхідності можна використовувати вкладки або додаткові сторінки форм;

- угруповання - елементи управління в формі необхідно групувати за змістом, використовуючи елементи угруповання: рамки, фрейми;

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

Тут перераховані основні принципи, які варто врахувати при проектуванні інтерфейсу програми.

 

2.3.2 Графічний інтерфейс користувача. Правильне використання кольорів робить інтерфейс користувача більш зручним для розуміння й керування. Разом з тим використання кольорів може бути неправильним, що візуально неприємно і навіть провокує помилки. Основним принципом розробників графічного інтерфейсу користувача повинно бути обережне використання кольорів на екранах. Існує 14 правил ефективного використання кольору у графічному інтерфейсі. Найбільш важливі такі:

1. Використовуйте обмежену кількість кольорів. Для вікон не треба використовувати більше за чотири або п`яти різних кольорів, в інтерфейсі системи не повинно бути більше за сім кольорів.

2. Використовуйте різні кольори для показу змін у стані систем. Якщо на екрані змінилися кольори, значить відбулась деяка подія. Виділення кольором особливо необхідно на складних екранах, на яких відображаються сотні різних об`єктів.

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

4. Використовуйте кольорове кодування помірковано й послідовно. Якщо у деякій частині системи повідомлення про помилку відображається, наприклад, червоним кольором, то у всіх інших частинах подібні повідомлення повинні відображатися таким самим кольором. Тоді червоний колір не треба використовувати ні де більше. Слід також пам’ятати, що у користувача може бути власне уявлення про значення окремих кольорів.

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

 

Програмне рішення

 

2.4.1 Вибір моделі процесу створення ПЗ. Тенденції розвитку сучасних інформаційних технологій ведуть до постійного збільшення складності програмних продуктів. Створення програмного забезпечення є складним ітеративним процесом, де об’єкт проектування повинен бути адекватно описаний. Це досить складна та тривала за часом робота, яка потребує висококваліфікованих спеціалістів.

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

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

2.4.2 Вибір платформи. Розробка проекту модуля «Облік персоналу» для АІС «Управління персоналом корпорації» передбачає впровадження її на базі будь-якого підприємства. Тому для розроблення проекту модуля я обрала наступний програмний продукти.

Microsoft Access – реляційна система управління базами даних (СУБД). Іншими словами – це додаток для створення і ведення баз даних, а також їх редагування. Основним завдань розробників була зручність і простота програми. Покращений інтерфейс, безліч вбудованих шаблонів і сучасні інструменти обробки даних дозволять користувачеві оперативно й ефективно впоратися з великими обсягами даних, відстежити ключову інформацію, спростити управління та аналіз даних.

Microsoft Access - це настільна система керування базами даних (СУБД), призначена для роботи на автономному персональному комп'ютері або в локальній обчислювальній мережі під управлінням сімейства операційних систем Microsoft Windows. СУБД Microsoft Access володіє потужними, зручними і гнучкими засобами візуального проектування об'єктів за допомогою Майстрів, що дозволяє користувачеві при мінімальній попередній підготовці досить швидко розробити повноцінну інформаційну систему на рівні таблиць, запитів, форм і звітів. Дані бази даних зберігаються в таблицях.

Основні можливості СУБД Microsoft Access:

· проектування базових об’єктів – двовимірні таблиці з полями різних типів даних;

· створення зв’язків між таблицями, з підтримкою цілісності даних, каскадного відновлення полів і каскадного видалення записів;

· введення, зберігання, перегляд, сортування, зміна й вибірка даних з таблиць із використанням різних засобів контролю інформації, індексування таблиць і апарата алгебри логіки;

· створення, модифікація й використання похідних об’єктів (запитів, форм і звітів).

Microsoft Access працює з об’єктами шести типів: таблицями, формами, запитами, звітами, модулями, макросами.

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

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

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

 

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

У створеній базі даних (БД) вся інформація зберігається в таких таблицях:

Таблиця 2.1

Відпустка

Фізичне ім’я	PK	Тип	Функціонал
Номер розпорядження	✓	Текстовий	Унікальний номер розпорядження
Дата розпорядження		Дата/час	Дата видачі розпорядження
Табельний номер		Числовий	Унікальний номер працівника
ПІБ		Текстовий	Прізвище, ім’я, по батькові працівника
Назва підрозділу		Текстовий	Назва підрозділу в якому працює працівник
Назва професії		Текстовий	Назва посади яку посідає працівник
Кваліфікація		Текстовий	Кваліфікація працівника
Вид відпустки		Текстовий	Вид відпустки яка надається працівникові
За період з		Дата/час	Період роботи з
За період по		Дата/час	Період роботи по
Період з		Дата/час	Період відпустки з
Період по		Дата/час	Період відпустки по
Календарні дні		Числовий	Кількість дні відпустки
Надання матеріальної		Логічний	Надання матеріальної допомоги на оздоровлення
Підпис		Текстовий	Підпис керівника
Продовження таблиці 2.1
ПІБ керівника		Текстовий	Прізвище, ім’я, по батькові керівника
Підпис підрозділу		Текстовий	Підпис керівника підрозділу
ПІБ підрозділу		Текстовий	Прізвище, ім’я, по батькові керівника підрозділу
Підпис працівника		Текстовий	Підпис працівника
Дата прийняття		Дата/час	Дата підписання розпорядження

 

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

Таблиця 2.2

Відрядження

Фізичне ім’я	PK	Тип	Функціонал
Номер розпорядження	✓	Текстовий	Унікальний номер розпорядження
Дата видачі наказу		Дата/час	Дата видачі наказу
Місто видачі наказу		Текстовий	Місто в якому видається наказ про відрядження
Табельний номер		Числовий	Унікальний номер працівника
ПІБ		Текстовий	Прізвище, ім’я, по батькові працівника
Пункт призначення		Текстовий	Місто в яке направляється робітник
Продовження таблиці 2.2
Підприємство		Текстовий	Підприємство в яке направляється робітник
Дата початку відрядження		Дата/час	Дата початку відрядження
Дата закінчення відрядження		Дата/час	Дата закінчення відрядження
Мета відрядження		Текстовий	Мета відрядження працівника
Підпис керівника		Текстовий	Підпис керівника
ПІБ керівника		Текстовий	Прізвище, ім’я, по батькові керівника
Підпис працівника		Текстовий	Підпис працівника
ПІБ працівника		Текстовий	Прізвище, ім’я, по батькові працівника

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

Таблиця 2.3

Звільнення

Фізичне ім’я	PK	Тип	Функціонал
Номер розпорядження	✓	Текстовий	Унікальний номер розпорядження
Дата розпорядження		Дата/час	Дата видачі розпорядження
Дата звільнення		Дата/час	Дата звільнення робітника
Табельний номер		Числовий	Унікальний номер працівника
ПІБ		Текстовий	Прізвище, ім’я, по батькові працівника
Продовження таблиці 2.3
Назва підрозділу		Текстовий	Назва підрозділу в якому працює робітник
Назва професії		Текстовий	Назва займаної посади
Класифікація		Дата/час	Вид класифікаційного угруповання
Причина звільнення		Дата/час	Причина звільнення працівника
Підстава звільнення		Текстовий	Підстава звільнення працівника
Вихідна допомога		Логічний	Надання вихідна допомога
Вихідна допомога, грн.		Грошовий	Надання вихідної допомоги в грн.
Компенсація		Логічний	Надання компенсації
Кількість днів		Числовий	Компенсація за кількість календарних днів невикористаної щорічної відпустки
Утримати		Логічний	Утримати за невідпрацьовану частину робочого року
Кількість днів		Числовий	Утримати за календарні дні, що були надані в рахунок невідпрацьованої частини робочого року
Підпис		Текстовий	Підпис керівника
ПІБ керівника		Текстовий	Прізвище, ім’я, по батькові керівника
Підпис працівника		Текстовий	Підпис працівника
Дата прийняття		Дата/час	Дата підписання розпорядження

 

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

Таблиця 2.4