Облік технічного обслуговування автотранспорту

Кожна система, незалежно від її типу та масштабу, проходить життєвий цикл відповідно до деякої інструкції від свого початкового задуму до остаточного припинення використання. Просування системи по частинах цієї інструкції, в якій би то не було послідовності та яким би то не було чином, називається життєвим циклом системи [27]. Опис ЖЦ, таким чином, — це концептуальна сегментація визначення потреби в системі, її реалізації у вигляді продукції або послуги і її використання, еволюції та виведення з експлуатації. Опис ЖЦ зазвичай сегментовано по фазах, які складаються з однієї або декількох задач, в результаті виконання яких досягається один або декілька основних результатів [28]. Поділ на фази сприяє плануванню, розгортанню, експлуатації та підтримки цільової АС. 

На рис. 2.1 представлена узагальнена схема процесу розробки ЖЦ програмного забезпечення.

 

Рисунок 2.1. Узагальнена схема процесу розробки

 

Стадії ЖЦ системи можуть повторюватися ітераційним чином у зв’язку з поступовим уточненням вимог до системи та/або з необхідністю її адаптації до тих змін, які виникають в предметній області системи. Такий цикл проходять всі технічні, технологічні та інші інформаційні системи і в кожному випадку вони повинні бути економічно обґрунтовані і прив’язані до конкретних умов виробництва [29]. Основною причиною застосування описів життєвого циклу є потреба в прийнятті рішень за певними критеріями до переходу процесу розробки на наступну стадію АС. 

Сучасні моделі життєвих циклів

Каскадна модель. Каскадна модель демонструє класичний підхід до розробки різноманітних систем в будь-яких прикладних областях. Вона передбачує послідовну організацію робіт, де головною особливістю є розбиття всього процесу розробки на етапи, причому перехід з одного етапу на інший здійснюється тільки в тому випадку, коли всі роботи на попередньому кроці були завершені (рис. 2.2) [30].

З плином часу стадії каскадної моделі не раз видозмінювались, але все ж можна виділити шість основних етапів розробки:

 

Рисунок 2.2. Каскадна модель ЖЦ розробки

 

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

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

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

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

На п’ятому етапі проводиться перевірка отриманого програмного забезпечення на предмет відповідності вимогам, заявленим в технічному завданні. Дослідна експлуатація дозволяє виявити різного роду приховані недоліки, які проявляються в реальних умовах роботи АС.

Останній етап — супровід готового проекту. Даний етап включає в себе існування програмного продукту. Головне завдання цього етапу — переконати замовника, що всі його вимоги виконані повною мірою[31].

Нижче представлений реальний процес розробки по каскадній моделі (рис. 2.3).

 

Рис. 2.3 — Реальний процес розробки по каскадній моделі

 

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

Спіральна модель. В рамках даної моделі розробки АС (рис. 2.4) вибудовується наступна спіральна послідовність: аналіз вимог — проектування — реалізація — тестування. Така послідовність виконується неодноразово. Основними причинами повторювань виступають необхідність попередження ризиків та представлення Замовнику часткову версію проекту для отримання відкликів та побажань. Якщо розроблювана система достатньо складна, то треба виконувати проміжкові ітерації, не відкладаючи цю фазу на кінець, як це передбачає каскадна модель [32].

 

Рисунок 2.4 — Спіральна модель ЖЦ розробки

 

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

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