- •1 Розробка плану проекту
- •1.1 Аналіз та постановка задачі
- •1.2 Обґрунтування вибору моделі життєвого циклу для реалізації проекту
- •1.2.1 Каскадна модель.
- •1.2.2 Ітераційна модель.
- •1.2.3 Спіральна модель.
- •1.3 Обґрунтування вибору мови програмування та case-засобів
- •1.4 Розробка графіка виконання робіт по проекту у контексті обраної моделі життєвого циклу
- •1.5 Аналіз ризиків проекту та управління ними
- •1.6 Системна специфікація вимог до розроблюваного проекту
- •1.6.1 Розробка користувальницьких (функційних) вимог
- •1.6.2 Нефункційні вимоги до програмного забезпечення
- •2 Вибір та аналіз існуючих алгоритмів побудови шляху на карті
- •2.1 Точні алгоритми
- •2.1.1 Пошук в ширину на незваженому графі.
- •2.1.2 Алгоритм Флойда-Уоршелла
- •2.1.3 Алгоритм Дейкстри
- •2.2 Евристичні алгоритми
- •2.2.1 Алгоритм a*
- •2.2.2 Алгоритм d* Lite
- •3 Розробка архітектури програмного забезпечення
- •3.1.1 Діаграма варіантів використання
- •3.1.2 Діаграма класів
- •3.1.3 Діаграма станів
- •3.1.4 Діаграма діяльності
- •3.2 Блок-схеми алгоритмічної частини програмного забезпечення
- •4 Кодування і тестування пз
- •4.1 Особливості реалізації програмного забезпечення
- •4.2 Допоміжні засоби для реалізації програмного забезпечення
- •4.3 Тестування пз
- •4.4 Представлення результатів тестування пз (у хронологічному порядку, які помилки були виявлені і виправлені)
- •4.5 Представлення результатів, що демонструють функціональність розробленого пз
- •4.6 Основні функції розробленого програмного забезпечення
- •5 Надійність програмного забезпечення
- •5.1 Поняття надійності програмного забезпечення
- •5.2 Класифікація моделей надійності програмного забезпечення
- •5.3 Розрахункова частина
- •6 Економічний розділ
- •6.1 Обґрунтування доцільності створення локальної мережі
- •6.2 Кошторис на розробку програмного продукту
- •6.2.1 Основна заробітна плата розробників (дослідників):
- •6.2.2 Амортизація обладнання, комп'ютерів та приміщень, які використовувались для розробки нового технічного рішення.
- •6.2.3 Оренда обладнання, устаткування, приміщень, які були використані в ході здійснення розробки нового технічного рішення.
- •6.2.4 Витрати на комплектуючі к, що були використані на розробку нового технічного рішення, розраховуються за формулою:
- •7.2 Забезпечення електробезпеки при експлуатації комп’ютерної техніки
- •7.3 Розрахунок загального штучного рівномірного освітлення приміщення люмінесцентними лампами методом коефіцієнта використання світлового потоку
- •Висновки
- •Перелік посилань
1.6 Системна специфікація вимог до розроблюваного проекту
Специфікація вимог програмного забезпечення (англ. Software Requirements Specification, SRS) - повний опис поведінки програмного забезпечення, яке необхідно розробити.
Включає ряд користувальницьких сценаріїв (англ. usecases), які описують всі варіанти взаємодії між користувачами і програмним забезпеченням.
Користувальницькі сценарії є засобом представлення функціональних вимог. На додаток до призначених для користувача сценаріїв, специфікація також містить нефункційні вимоги, які накладають обмеження на дизайн або реалізацію(такі як вимоги продуктивності, стандарти якості, або проектні обмеження).
1.6.1 Розробка користувальницьких (функційних) вимог
Зважаючи на специфіку даного проекту можна виділити наступні користувальницькі вимоги до програмного забезпечення:
завантаження карти місцевості, на якій знаходиться мобільна платформа;
оновлення карти місцевості при переміщенні у часі певного об'єкта на ній;
встановлення точки, до якої необхідно прокласти шлях руху мобільної платформи;
отримання результату - траєкторій руху для мобільної платформи.
1.6.2 Нефункційні вимоги до програмного забезпечення
Оскільки дане програмне забезпечення являє собою частину у вигляді підмодуля великого проекту, то основні нефункційні вимоги до нього побудовані зважаючи на роботу не лише як окремої програми, а й як частини програмного забезпечення усієї системи.
Основні вимоги, які можна виділити:
висока надійність, відказостійкість. Розроблене програмне забезпечення повинне працювати з будь-якими можливими даними, що надходять із інших рівнів глобального проекту, обробляти дані за одним й тим самим правильним (для розрахунку траєкторії) алгоритмом, а також безпечно обробляти помилки при некоректних даних;
висока точність обрахунку траєкторії пересування. Усі розрахунки мають проводитись за перевіреним та відтестованим алгоритмом, який видає оптимальний (або наближений до оптимального) результат. У випадку, коли результат (траєкторії руху) обрахувати неможливо (наприклад, через особливість ландшафту чи велику кількість перешкод, через які неможливий шлях), то програма повинна повідомити про це, а не зациклюватись/аварійно завершитись/тощо;
висока швидкодія. Один із основних критеріїв при розробці даного програмного забезпечення. Основою даного програмного забезпечення є алгоритм пошуку шляху на графі (карті місцевості). Обраний алгоритм повинен знаходити шлях за лінійний чи сублінійний час (O(N) та O(NlogN) відповідно [6]) без використання певних евристичних методів у найгіршому випадку. Найкращим рішенням буде використання алгоритму, який за допомогою певних евристичних методів дає прискорення в часі роботи програмного забезпечення на кілька порядків.
2 Вибір та аналіз існуючих алгоритмів побудови шляху на карті
Усі алгоритми пошуку оптимального шляху на графі, які розглянуті в даній роботі, можна розділити на 2 види: точні (строгі) та наближенні (евристичні). Основними відмінностями між цими двома типами є:
точність – строгі алгоритми гарантують оптимальний результат, тоді як евристичні алгоритми можуть давати похибку у вимірюваннях на певній кількості вхідних даних;
швидкодія – евристичні алгоритми за рахунок певних спрощень та використання вірогідних і наближених проміжних значень обрахунку дають значний приріст у швидкості роботи програми в порівнянні з точними алгоритмами.
Розглянемо обидва види алгоритмів для вирішення задачі пошуку траєкторії слідування мобільної платформи.