Процес розробки програмного забезпечення

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук
ТРПЗ
Цикл розробки програмного забезпечення
Coding Shots Annual Plan high res-5.jpg
Програміст за роботою
Діяльність та кроки
Вимоги • Специфікація • Архітектура • Дизайн • Реалізація • Тестування • Розгортання (Реліз) • Супровід
Методології • Процес
Гнучка • Чистого приміщення • DSDM • Ітеративна • RAD • RUP • Спіраль • Водоспад • XP • Scrum • Lean • V-Model • FDD • TDD • BDD
Допоміжні дисципліни
Керування конфігурацією • Документування • Якість ПЗ • Управління проектами • Досвід користування
Інструменти
Компілятор • Зневаджувач • Профілювальник • GUI designer • IDE

Процес розробки програмного забезпечення (англ. software development process, software process) — структура, відповідно до якої побудована розробка програмного забезпечення (ПЗ).

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

Кроки процесу[ред.ред. код]

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

Моделі процесу[ред.ред. код]

Водоспадна (каскадна, послідовна) модель[ред.ред. код]

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

Етапи проекту у відповідності з каскадною моделлю:

  1. Формування вимог;
  2. Проектування;
  3. Реалізація;
  4. Тестування;
  5. Впровадження;
  6. Експлуатація та супровід.

Переваги

  • Повна і погоджена документація на кожному етапі;
  • Легко визначити терміни і витрати на проект.

Недоліки

У водоспадної моделі перехід від однієї фази проекту до іншого передбачає повну коректність результату (виходу) попередньої фази. Однак неточність будь-якої вимоги або некоректна його інтерпретація в результаті призводить до того, що доводиться «відкочуватися» до ранньої фазі проекту і необхідна переробка не просто вибиває проектну команду з графіка, але часто призводить до якісного зростання витрат і, не виключено, до припинення проекту в тій формі, в якій він спочатку замислювався. На думку сучасних фахівців, основна помилка авторів водоспадної моделі полягає у припущеннях, що проект проходить через весь процес один раз, спроектована архітектура хороша і проста у використанні, проект здійснення розумний, а помилки в реалізації легко усуваються в міру тестування. Ця модель виходить з того, що всі помилки будуть зосереджені на реалізації, а тому їх усунення відбувається рівномірно під час тестування компонентів і системи[1]. Таким чином, водоспадна модель для великих проектів мало реалістична і може бути ефективно використана тільки для створення невеликих систем[2].

Ітераційна модель[ред.ред. код]

Альтернативою послідовної моделі є так звана модель ітеративної та інкрементальної розробки (англ. iterative and incremental development, IID), отримала також від Т. Ґілба в 1970-ті назву еволюційної моделі. Також цю модель називають ітеративної моделлю та інкрементальною моделлю[3].

Модель IID передбачає розбиття життєвого циклу проекту на послідовність ітерацій, кожна з яких нагадує «міні-проект», включаючи всі процеси розробки в застосуванні до створення менших фрагментів функціональності, порівняно з проектом в цілому. Мета кожної ітерації — отримання працюючої версії програмної системи, що включає функціональність, визначену інтегрованим змістом усіх попередніх і поточної ітерації. Результат фінальної ітерації містить всю необхідну функціональність продукту. Таким чином, із завершенням кожної ітерації продукт отримує приріст — інкремент — до його можливостей, які, отже, розвиваються еволюційно. Ітеративності, инкрементальность і еволюційність в даному випадку є вислів одного і того ж сенсу різними словами зі злегка різних точок зору[2].

За висловом Ґілба, «еволюція — прийом, призначений для створення видимості стабільності. Шанси успішного створення складної системи будуть максимальними, якщо вона реалізується у серії невеликих кроків і якщо кожен крок містить у собі чітко визначений успіх, а також можливість „відкату“ до попереднього успішному етапу в разі невдачі. Перед тим, як пустити в справу всі ресурси, призначені для створення системи, розробник має можливість одержувати з реального світу сигнали зворотного зв'язку і виправляти можливі помилки в проекті»[3].

Підхід IID має і свої негативні сторони, які, по суті, — зворотній бік чеснот. По-перше, цілісне розуміння можливостей і обмежень проекту дуже довгий час відсутня. По-друге, при ітераціях доводиться відкидати частину раніше зробленої роботи. По-третє, сумлінність фахівців при виконанні робіт все ж знижується, що психологічно зрозуміло, адже над ними постійно тяжіє відчуття, що «все одно все можна буде переробити і поліпшити пізніше»[2].

Різні варіанти ітераційного підходу реалізовані в більшості сучасних методологій розробки (RUP, MSF, XP).

Спіральна модель[ред.ред. код]

Спіральна модель (англ. spiral model) була розроблена в середині 1980-х років Баррі Боэмом. Вона заснована на класичному циклі Демінга PDCA (plan-do-check-act). При використанні цієї моделі ЗА створюється в кілька ітерацій (витків спіралі) методом прототипування.

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

На кожній ітерації оцінюються:

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

Важливо розуміти, що спіральна модель є не альтернативою еволюційної моделі (моделі IID), а спеціально опрацьованим варіантом. На жаль, нерідко спіральну модель або помилково використовують як синонім еволюційної моделі взагалі, або (не менш помилково) згадують як абсолютно самостійну модель поряд з IID[2].

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

  1. Дефіцит фахівців.
  2. Нереалістичні терміни і бюджет.
  3. Реалізація не відповідає функціональності.
  4. Розробка неправильного користувальницького інтерфейсу.
  5. Перфекціонізм, непотрібна оптимізація та покращення деталей.
  6. Безперервний потік змін.
  7. Брак інформації про зовнішні компоненти, що визначають оточення системи або залучених в інтеграцію.
  8. Недоліки в роботах, що виконуються зовнішніми (по відношенню до проекту) ресурсами.
  9. Недостатня продуктивність одержуваної системи.
  10. Розрив у кваліфікації фахівців різних областей.

У сьогоднішній спіральної моделі визначено наступний загальний набір контрольних точок[4]:

  1. Concept of Operations (COO) — концепція (використання) системи;
  2. Life Cycle Objectives (LCO) — цілі і зміст життєвого циклу;
  3. Life Cycle Architecture (LCA) — архітектура життєвого циклу; тут можливо говорити про готовність концептуальної архітектури цільової програмної системи;
  4. Initial Operational Capability (IOC) — перша версія створюваного продукту, придатна для дослідної експлуатації;
  5. Final Operational Capability (FOC) — готовий продукт, розгорнутий (встановлений і налаштований) для реальної експлуатації.

Примітки[ред.ред. код]

  1. Брукс Ф. Міфічний людино-місяць, або як створюються програмні системи : пер. з англ. / Ф. Брукс. — Санкт-Петербург : Символ-Плюс, 1999. — 304 с.: іл.
  2. а б в г Мірошниченко Е. А. Технології програмування: навчальний посібник / Е. А. Мірошниченко. — 2-е изд., испр. і дод. — Томськ: Изд-во Томського політехнічного університету, 2008. — 128 с.
  3. а б Ларман К. Ітеративна та інкрементальна розробка: коротка історія / К. Ларман, Ст. Базілю // Відкриті системи. — 2003.
  4. Орлик С.