4.1 Діаграма варіантів використання
Дана діаграма ілюструє процес взаємодії дійових осіб у системі (акторів), дії які вони можуть виконувати та зв’язки, які їх поєднують між собою.
Як видно з діаграми в даній системі є тільки 4 дійових особи:
Замовник
Диспетчер
Водій TAXI
Адміністратор
Замовник (тобто той, хто замовляє автомобільне перевезення) і водій мають доволі абстрактне значення, оскільки у використанні самої програми не будуть приймати участь, але у моделі взаємодії вони приймають безпосередню роль. Замовник – замовляє автомобільне перевезення, а - водій виконує його. Проте замовник не спілкується на пряму з водієм, а через диспетчера, який в свою чергу оформляє заявку на замовлення і створює відповідний запис у базі даних.
Таким чином, таксопарк дуже легко в кінці місяця може сформувати статистику і підрахувати скільки автомобільних перевезень було здійснено окремими водіями і нарахувати їм заробітну плату.
Адміністратор в свою чергу має право наймати водіїв на роботу, або звільняти їх, також він має право розпоряджатись майном, тобто автомобілями.
Рисунок 4.1 – Діаграма варіантів використання.
4.2 Діаграма класів
Діаграма класів проектованої системи відображає основні структурні одиниці коду так, як вони і будуть присутні в тексті програми фізично (або ж відображає архітектуру програми). З рисунку 6.2 видно, що в системі будуть присутні три основні компоненти – Засіб авторизації, графічний інтерфейс користувача та драйвер доступу до бази даних, в останьому буде міститись логіка запису та вибірки полів з БД, також за допомогою останньої компоненти підключатиметься БД. (Дана діаграма не є точною і остаточною діаграмою класів)
Рисунок 4.2 – Діаграма класів.
4.3 Концептуальна діаграма бази даних
Концептуальна схема бази даних не являється UMLдіаграмою, але вона є невід’ємною при проектуванні програмної системи, що містить хоча б одну базу даних.
Метою цієї діаграми є опис таблиць у базі даних, наявних у них полів та зв’язків поміж таблицями.
Рисунок 4.3 - Концептуальна схема бази даних.
4.4 Діаграма слідування
За допомогою даної діаграми прийнято відображати послідовності виконуваних дій, кожна з яких описує окрему гілку в виконанні програми.
Дана діаграма ілюструє лише фрагмент коду, а саме - проведення авторизації користувача. На діаграмі чітко видно, що пройти авторизацію можуть користувачі двох типів (адміністратор та диспетчер), кожен з яких має набір повноважень.
Рисунок 4.4 – Діаграма слідування.
Управління ризиками
Ризик (з грець. risikon — стрімчак) — небезпека втрат, непередбачуваних подій та дій розрахунку на щасливий випадок. Ризик є об’єктивним явищем, природа якого викликана неоднозначністю, невизначеністю подій. Невизначеність — це множина станів внутрішнього та зовнішнього середовища проекту. Проектний ризик — це небезпека небажаних відхилень від очікуваних станів проекту в майбутньому, із розрахунку яких і приймаються рішення в даний момент. Ризик у проекті є комбінацією обмежень і невизначеності. Можна звести до мінімуму ризик в проекті шляхом або усунення обмежень (що є достатньо проблематичним), або пошуку і зниження невизначеності. Планування та реалізація проектів відбувається в умовах невизначеності, яка породжується зміною внутрішнього та зовнішнього середовищ. Під невизначеністю розуміють відсутність повної та достовірної інформації про умови реалізації проекту. За характером дії ризики поділяють напрості та складні. Складні ризики є комбінацією простих ризиків.Прості ризикизумовлюються дією сукупності незалежних між собою подій. Отже ми визначили, щоризик у проекті є комбінацією обмежень і невизначеності.
Невизначеність в проекті може бути спричинена неспроможністю:
– визначити цілі проекту;
– зрозуміти, хто є зацікавленими особами цього проекту;
– призначення кваліфікованих фахівців, які підтримуються керівником, в команду проекту;
– точно оцінити витрати;
– визначити точно кінцевих користувачів результатів проекту;
– забезпечити хороші умови роботи команді проекту;
– зв'язати всіх людей, залучених в проект, контрактами або документами про взаєморозуміння.
Завдання управління ризиками полягає у зменшенні впливу небажаних факторів на життєвий цикл проекту для отримання результатів, найближчих до бажаних. Можливості маневрування під час управління ризиками доволі різноманітні: запобігання ризику, відхилення від ризику, свідоме і неусвідомлене прийняття ризику, дублювання операцій, об'єктів чи ресурсів, скорочення величини потенційних і фактичних втрат, розподіл ризику, розукрупнення ризику, рознесення експозицій у просторі та у часі, ізоляція небезпечних чинників один від одного, перенесення (страховий та нестраховий трансфер) ризику на інших агентів тощо. Однак, яким би не був той чи інший метод управління ризиком, взагалі усунути ризик не вдасться, адже у довільній системі завжди існує певний рівень залишкової ентропії.
Проте не все так погано, тому що ризики можна зменшити, існує багато способів для зменшення ризиків, зокрема широкого розповсюдження набула технологія зменшення стану невизначеності при оцінюванні ризику шляхом розбивки статті ризику на її складові елементи. Сумарна оцінка відхилень по компонентах є меншою, ніж відхилення всієї статті ризику. Поділ процесу на компоненти відбувається доти, поки відхилення всіх компонентів вартості не знизиться нижче допустимої межі. Аналогічна техніка використовується при оцінці тривалості заходів, які визначають графік проекту, в результаті чого знижується невизначеність оцінки тривалості проекту. Ризик — це не обов’язково погано. Це загальна властивість всіх проектів. Будь-який проект має деяку міру невизначеності через початкові обмеження і мінливе оточення, в якому вони виконуються.
Ризик має три основні атрибути:
1) випадок, що містить ризик;
2) ймовірність;
3) наслідок (дія ризику).
Необхідно зрозуміти природу ризику і визначати, в яких ситуаціях він може виникнути
Ймовірність виникнення можна виміряти в кількісних (ведеться імовірнісна оцінка події в межах 0–100%), рідше в якісних показниках.
Ймовірність ризику (risk probability) — це міра можливості того, що наслідок ризику дійсно буде мати місце.
Загроза ризику (risk impact) — міра серйозності негативних наслідків, рівень збитків або оцінка потенційних можливостей, пов’я-заних з ризиком.
Є декілька видів випадків, які містять ризик для проекту:
1. Випадки, які можуть статися.
2. Випадки, які матимуть великі наслідки, якщо вони відбудуться.
3. Випадки поза вашим контролем.
4. Випадки, про які вам відомо дуже мало. Класифікація основних видів ризиків в проекті здійснюється затакими критеріями:
В залежності від джерела виникнення:
– природно-кліматичні;
– технічні;
– виробничі;
– економічні;
– ринкові;
– фінансові;
– соціальні;
– політичні;
– інноваційні;
– регіональні;
– галузеві;
– ризики навмисних дій (вандалізм, нечесність).
В залежності від місця виникнення:
– зовнішні;
– внутрішні.
В залежності від тяжкості проявів:
– втрачена вигода;
– збитки;
– втрата;
– банкрутство.
За ступенем передбачуваності:
– передбачувані з малою ймовірністю;
– непередбачувані.
Нижче сформульовані можливі ризики щодо розроблюваного нами проекту.
Таблиця 1 – Ризики за групами.
|
|
Ризики за групами |
|
|
Технологічні та технічні ризики |
|
1. |
Відмова апаратури |
|
2. |
Неправильний вибір середовища програмування |
|
3. |
Помилки проектування |
|
|
Ризики, пов’язані з персоналом |
|
4. |
Неправильний підбір команди |
|
5. |
Відсутнісь досвіду |
|
6. |
Звільнення учасника команди |
|
|
Організаційні |
|
7. |
Неправильний розподіл обов’язків в команді |
|
8. |
Низька якість планування робіт |
|
9. |
Низька якість виконання проектних робіт |
|
10. |
Недотримання графіка |
|
11 |
Недотримання термінів виконання проекту |
|
12. |
Невизначеність цілей, інтересів та поведінки учасників проекту
|
|
|
Ризики |
Імовірність прояву |
Збитки |
|
|
|
Низька |
|
|
1. |
Неправильний вибір середовища програмування |
5% |
серйозні |
|
|
|
Близька до середньої |
|
|
2. |
Відмова апаратури |
10% |
серйозні |
|
3. |
Звільнення учасника команди |
10% |
серйозні |
|
4. |
Недотримання графіка |
10% |
терпимі |
|
5. |
Недотримання термінів виконання проекту |
10% |
катастрофічні |
|
6. |
Невизначеність цілей, інтересів та поведінки учасників проекту
|
10% |
серйозні |
|
7. |
Помилки проектування |
15% |
серйозні |
|
8. |
Низька якість планування робіт |
15% |
катастрофічні |
|
9. |
Неправильний підбір команди |
20% |
катастрофічні |
|
10. |
Неправильний розподіл обов’язків в команді |
20% |
серйозні |
|
11. |
Низька якість виконання проектних робіт |
20% |
катастрофічні |
|
|
|
Середня |
|
|
12. |
Відсутнісь досвіду |
30% |
серйозні |
Таблиця 2 – Ризики за імовірністю прояву.
Таблиця 3 – Ризики за наслідками.
|
|
Ризики |
Імовірність прояву |
Збитки |
|
1. |
Недотримання термінів виконання проекту |
10% |
катастрофічні |
|
2. |
Низька якість планування робіт |
15% |
катастрофічні |
|
3. |
Неправильний підбір команди |
20% |
катастрофічні |
|
4. |
Низька якість виконання проектних робіт |
20% |
катастрофічні |
|
5. |
Неправильний вибір середовища програмування |
5% |
серйозні |
|
6. |
Відмова апаратури |
10% |
серйозні |
|
7. |
Звільнення учасника команди |
10% |
серйозні |
|
8. |
Невизначеність цілей, інтересів та поведінки учасників проекту
|
10% |
серйозні |
|
9. |
Помилки проектування |
15% |
серйозні |
|
10. |
Неправильний розподіл обов’язків в команді |
20% |
серйозні |
|
11. |
Відсутнісь досвіду |
30% |
серйозні |
|
12. |
Недотримання графіка |
10% |
терпимі |
|
|
|
|
|
|
|
|
Вик. 1 |
Аналіз вимог |
Розробка документації |
Тестування ПЗ | ||
|
| |||||
|
Вик. 2 |
Формування ТЗ |
Розробка документації |
Проектування ЕС |
Реалізація ЕС |
Налагодження ПЗ |
|
| |||||
|
Вик. 3 |
Формування ТЗ |
Розробка документації |
Проектування БД |
Реалізація ЕС |
Налагодження ПЗ |
|
|
|
|
|
|
|
|
|
15 |
50 |
70 |
90 |
101 |
Виконавець 1 – Алексеев Євген.
Виконавець 2 – Гребенюк Богдан.
Виконавець 3 – Жумела Андрій.
КП
CПРм
008019.02.00.ТППС