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

Обгрунтування вибору моделі прототипування для створення бази даних станції технічного обслуговування

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

При використанні структурної еволюційної моделі швидкого прототипування для прийнятного проекту проявляються такі переваги:

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

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

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

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

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

документація сконцентрована на кінцевому продукті, а не на його розробці;

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

На основі аналізу моделей ЖЦ була побудована табл. 2.1 для порівняння найбільшої кількості переваг для потреб даного проекту.

 

Таблиця 2.1

Порівняння моделей ЖЦ для потреб даного проекту

Потреби Каскадна V-подібна Спіральна Прототипування

Чи часто потреби будуть змінюватись у циклі? Ні Ні Так Так

Чи потрібно демонструвати потреби з метою визначення? Ні НІ Так Так

Чи буде проект ідентифікувати новий напрям продукту для організації? Ні Ні Так Так

Чи буде система змынюватись можливо, з використанням непередбачуваних методів на етапі супроводження Ні Ні Так Так

Чи є достатніми ресурси (час, гроші, персонал)? Ні Ні Так Так

Чи будуть користувачі ознайомлені з проблемами предметної області? Ні Ні Ні Так

 

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

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

 

 

План проекту

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

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

Діаграма Ганта (англ. Gantt chart, також стрічкова діаграма, графік Ганта) — це популярний тип діаграм, який використовується для ілюстрації плану, графіка робіт за будь-яким проектом. Є одним з методів планування та управління проектами [41].

Структура декомпозиції робіт (WBS) має такі характеристики [42]:

Описує з необхідною точністю зміст робіт за проектом;

Визначає весь обсяг робіт за проектом;

Формується у вигляді ієрархічної структури (проект декомпозирується на пакети/субпакети і т. д. робіт).

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

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

Microsoft Project — система управління проектами, розроблена корпорацією Microsoft. Microsoft Project створений, щоб допомогти менеджерові проекту в розробці планів, розподілі ресурсів за завданнями, відстежуванні прогресу і аналізі обсягів робіт [43].

Задача плану проекту ― в деталізації етапів ЖЦ у формальному документі. Побудова календарного плану починається зі структури поопераційної розбивки робіт або WBS (Work Breakdown Strukture, структура декомпозиції робіт). Для даного дипломного проекту розпишемо примірний план створення проекту, який представлений на рис. 3.1.

 

Рисунок 3.1 — Календарний план дипломного проекту

 

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

Швидкий аналіз

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