Процес розробки програмного забезпечення (англ. software development process, software process) — сукупність ряду послідовних дій, спрямованих на розробку програмного забезпечення (ПЗ).
Існує кілька моделей такого процесу, кожна з яких описує свій підхід, у вигляді завдань і/або діяльності, які мають місце в ході процесу. Вибір тієї або іншої моделі здійснюється відповідно до обраної методології розробки програмного забезпечення.
Кроки процесу
Процес розробки складається з безлічі підпроцесів, або дисциплін, деякі з яких показані нижче. У моделі водоспаду вони йдуть одна за одною, в інших аналогічних процесах їх порядок або склад змінюється.
Моделі процесу
Водоспадна (каскадна, послідовна) модель
Водоспадна модель життєвого циклу (англ. waterfall model) була запропонована в 1970 р. Вінстоном Ройсом. Вона передбачає послідовне виконання всіх етапів проєкту в строго фіксованому порядку. Перехід на наступний етап означає повне завершення робіт на попередньому етапі. Вимоги, визначені на стадії формування вимог, суворо документуються у вигляді технічного завдання і фіксуються на весь час розробки проєкту. Кожна стадія завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників.
Етапи проєкту у відповідності з каскадною моделлю:
- Формування вимог;
- Проєктування;
- Реалізація;
- Тестування;
- Впровадження;
- Експлуатація та супровід.
Переваги
- Повна і погоджена документація на кожному етапі;
- Легко визначити терміни і витрати на проєкт.
Недоліки
У водоспадної моделі перехід від однієї фази проєкту до іншого передбачає повну коректність результату (виходу) попередньої фази. Однак неточність будь-якої вимоги або некоректна його інтерпретація в результаті призводить до того, що доводиться «відкочуватися» до ранньої фази проєкту і необхідна переробка не просто вибиває проєктну команду з графіка, але часто призводить до якісного зростання витрат і, не виключено, до припинення проєкту в тій формі, в якій він спочатку замислювався. На думку сучасних фахівців, основна помилка авторів водоспадної моделі полягає у припущеннях, що проєкт проходить через весь процес один раз, спроєктована архітектура хороша і проста у використанні, проєкт здійснення розумний, а помилки в реалізації легко усуваються в міру тестування. Ця модель виходить з того, що всі помилки будуть зосереджені на реалізації, а тому їх усунення відбувається рівномірно під час тестування компонентів і системи. Таким чином, водоспадна модель для великих проєктів мало реалістична і може бути ефективно використана тільки для створення невеликих систем.
Ітераційна модель
Альтернативою послідовної моделі є так звана модель ітеративної та інкрементальної розробки (англ. iterative and incremental development, IID), отримала також від Т. Ґілба в 1970-ті назву еволюційної моделі. Також цю модель називають ітеративною та інкрементальною моделлю.
Модель IID передбачає розбиття життєвого циклу проєкту на послідовність ітерацій, кожна з яких нагадує «міні-проєкт», включаючи всі процеси розробки в застосуванні до створення менших фрагментів функціональності, порівняно з проєктом в цілому. Мета кожної ітерації — отримання версії програмної системи, що працює та включає функціональність, визначену інтегрованим змістом усіх попередніх і поточної ітерації. Результат фінальної ітерації містить всю необхідну функціональність продукту. Таким чином, із завершенням кожної ітерації продукт отримує приріст — інкремент — до його можливостей, які, отже, розвиваються еволюційно. Ітеративність, інкрементальність і еволюційність в даному випадку є вислів одного і того ж сенсу різними словами зі злегка різних точок зору.
За висловом Ґілба, «еволюція — прийом, призначений для створення видимості стабільності. Шанси успішного створення складної системи будуть максимальними, якщо вона реалізується у серії невеликих кроків і якщо кожен крок містить у собі чітко визначений успіх, а також можливість „відкату“ до попереднього успішного етапу в разі невдачі. Перед тим, як пустити в справу всі ресурси, призначені для створення системи, розробник має можливість одержувати з реального світу сигнали зворотного зв'язку і виправляти можливі помилки в проєкті».
Підхід IID має і свої негативні сторони, які, по суті, — зворотній бік чеснот. По-перше, цілісне розуміння можливостей і обмежень проєкту дуже довгий час відсутнє. По-друге, при ітераціях доводиться відкидати частину раніше зробленої роботи. По-третє, сумлінність фахівців при виконанні робіт все ж знижується, що психологічно зрозуміло, адже над ними постійно тяжіє відчуття, що «все одно все можна буде переробити і поліпшити пізніше».
Різні варіанти ітераційного підходу реалізовані в більшості сучасних методологій розробки (RUP, MSF, XP).
Спіральна модель
Спіральна модель (англ. spiral model) була розроблена в середині 1980-х років Баррі Боэмом. Вона заснована на класичному циклі Демінга PDCA (plan-do-check-act). При використанні цієї моделі ЗА створюється в кілька ітерацій (витків спіралі) методом прототипування.
Кожна ітерація відповідає створенню фрагмента або версії ПЗ, на ньому уточнюються цілі і характеристики проєкту, оцінюється якість отриманих результатів і плануються роботи наступної ітерації.
На кожній ітерації оцінюються:
- ризик перевищення строків і вартості проєкту;
- необхідність виконання ще однієї ітерації;
- ступінь повноти і точності розуміння вимог до системи;
- доцільність припинення проєкту.
Важливо розуміти, що спіральна модель є не альтернативою еволюційної моделі (моделі IID), а спеціально опрацьованим варіантом. На жаль, нерідко спіральну модель або помилково використовують як синонім еволюційної моделі взагалі, або (не менш помилково) згадують як абсолютно самостійну модель поряд з IID.
Відмінною особливістю спіральної моделі є спеціальна увага, що приділяється ризикам, що впливає на організацію життєвого циклу, і контрольним точкам. Боем формулює 10 найбільш поширених (за пріоритетами) ризиків:
- Дефіцит фахівців.
- Нереалістичні терміни і бюджет.
- Реалізація не відповідає функціональності.
- Розробка неправильного користувальницького інтерфейсу.
- Перфекціонізм, непотрібна оптимізація та покращення деталей.
- Безперервний потік змін.
- Брак інформації про зовнішні компоненти, що визначають оточення системи або залучених в інтеграцію.
- Недоліки в роботах, що виконуються зовнішніми (стосовно проєкту) ресурсами.
- Недостатня продуктивність одержуваної системи.
- Розрив у кваліфікації фахівців різних областей.
У сьогоднішній спіральної моделі визначено наступний загальний набір контрольних точок:
- Concept of Operations (COO) — концепція (використання) системи;
- Life Cycle Objectives (LCO) — цілі і зміст життєвого циклу;
- Life Cycle Architecture (LCA) — архітектура життєвого циклу; тут можливо говорити про готовність концептуальної архітектури цільової програмної системи;
- Initial Operational Capability (IOC) — перша версія створюваного продукту, придатна для дослідної експлуатації;
- Final Operational Capability (FOC) — готовий продукт, розгорнутий (встановлений і налаштований) для реальної експлуатації.
Примітки
- Брукс Ф. Міфічний людино-місяць, або як створюються програмні системи: пер. з англ. / Ф. Брукс. — Санкт-Петербург: Символ-Плюс, 1999. — 304 с.: іл.
- Мірошниченко Е. А. Технології програмування: навчальний посібник / Е. А. Мірошниченко. — 2-е изд., испр. і дод. — Томськ: Изд-во Томського політехнічного університету, 2008. — 128 с.
- Ларман К. Ітеративна та інкрементальна розробка: коротка історія [ 13 жовтня 2016 у Wayback Machine.] / К. Ларман, Ст. Базілю // Відкриті системи. — 2003.
- Орлик С.
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
Proces rozrobki programnogo zabezpechennya angl software development process software process sukupnist ryadu poslidovnih dij spryamovanih na rozrobku programnogo zabezpechennya PZ Isnuye kilka modelej takogo procesu kozhna z yakih opisuye svij pidhid u viglyadi zavdan i abo diyalnosti yaki mayut misce v hodi procesu Vibir tiyeyi abo inshoyi modeli zdijsnyuyetsya vidpovidno do obranoyi metodologiyi rozrobki programnogo zabezpechennya Kroki procesuProces rozrobki skladayetsya z bezlichi pidprocesiv abo disciplin deyaki z yakih pokazani nizhche U modeli vodospadu voni jdut odna za odnoyu v inshih analogichnih procesah yih poryadok abo sklad zminyuyetsya Analiz vimog Specifikaciya programnogo zabezpechennya Proyektuvannya programnogo zabezpechennya Programuvannya Testuvannya programnogo zabezpechennya Sistemna integraciya Vprovadzhennya programnogo zabezpechennya abo Ustanovka programnogo zabezpechennya Suprovid programnogo zabezpechennyaModeli procesuVodospadna kaskadna poslidovna model Vodospadna model zhittyevogo ciklu angl waterfall model bula zaproponovana v 1970 r Vinstonom Rojsom Vona peredbachaye poslidovne vikonannya vsih etapiv proyektu v strogo fiksovanomu poryadku Perehid na nastupnij etap oznachaye povne zavershennya robit na poperednomu etapi Vimogi viznacheni na stadiyi formuvannya vimog suvoro dokumentuyutsya u viglyadi tehnichnogo zavdannya i fiksuyutsya na ves chas rozrobki proyektu Kozhna stadiya zavershuyetsya vipuskom povnogo komplektu dokumentaciyi dostatnoyi dlya togo shob rozrobka mogla buti prodovzhena inshoyu komandoyu rozrobnikiv Etapi proyektu u vidpovidnosti z kaskadnoyu modellyu Formuvannya vimog Proyektuvannya Realizaciya Testuvannya Vprovadzhennya Ekspluataciya ta suprovid Perevagi Povna i pogodzhena dokumentaciya na kozhnomu etapi Legko viznachiti termini i vitrati na proyekt Nedoliki U vodospadnoyi modeli perehid vid odniyeyi fazi proyektu do inshogo peredbachaye povnu korektnist rezultatu vihodu poperednoyi fazi Odnak netochnist bud yakoyi vimogi abo nekorektna jogo interpretaciya v rezultati prizvodit do togo sho dovoditsya vidkochuvatisya do rannoyi fazi proyektu i neobhidna pererobka ne prosto vibivaye proyektnu komandu z grafika ale chasto prizvodit do yakisnogo zrostannya vitrat i ne viklyucheno do pripinennya proyektu v tij formi v yakij vin spochatku zamislyuvavsya Na dumku suchasnih fahivciv osnovna pomilka avtoriv vodospadnoyi modeli polyagaye u pripushennyah sho proyekt prohodit cherez ves proces odin raz sproyektovana arhitektura horosha i prosta u vikoristanni proyekt zdijsnennya rozumnij a pomilki v realizaciyi legko usuvayutsya v miru testuvannya Cya model vihodit z togo sho vsi pomilki budut zoseredzheni na realizaciyi a tomu yih usunennya vidbuvayetsya rivnomirno pid chas testuvannya komponentiv i sistemi Takim chinom vodospadna model dlya velikih proyektiv malo realistichna i mozhe buti efektivno vikoristana tilki dlya stvorennya nevelikih sistem Iteracijna model Alternativoyu poslidovnoyi modeli ye tak zvana model iterativnoyi ta inkrementalnoyi rozrobki angl iterative and incremental development IID otrimala takozh vid T Gilba v 1970 ti nazvu evolyucijnoyi modeli Takozh cyu model nazivayut iterativnoyu ta inkrementalnoyu modellyu Model IID peredbachaye rozbittya zhittyevogo ciklu proyektu na poslidovnist iteracij kozhna z yakih nagaduye mini proyekt vklyuchayuchi vsi procesi rozrobki v zastosuvanni do stvorennya menshih fragmentiv funkcionalnosti porivnyano z proyektom v cilomu Meta kozhnoyi iteraciyi otrimannya versiyi programnoyi sistemi sho pracyuye ta vklyuchaye funkcionalnist viznachenu integrovanim zmistom usih poperednih i potochnoyi iteraciyi Rezultat finalnoyi iteraciyi mistit vsyu neobhidnu funkcionalnist produktu Takim chinom iz zavershennyam kozhnoyi iteraciyi produkt otrimuye pririst inkrement do jogo mozhlivostej yaki otzhe rozvivayutsya evolyucijno Iterativnist inkrementalnist i evolyucijnist v danomu vipadku ye visliv odnogo i togo zh sensu riznimi slovami zi zlegka riznih tochok zoru Za vislovom Gilba evolyuciya prijom priznachenij dlya stvorennya vidimosti stabilnosti Shansi uspishnogo stvorennya skladnoyi sistemi budut maksimalnimi yaksho vona realizuyetsya u seriyi nevelikih krokiv i yaksho kozhen krok mistit u sobi chitko viznachenij uspih a takozh mozhlivist vidkatu do poperednogo uspishnogo etapu v razi nevdachi Pered tim yak pustiti v spravu vsi resursi priznacheni dlya stvorennya sistemi rozrobnik maye mozhlivist oderzhuvati z realnogo svitu signali zvorotnogo zv yazku i vipravlyati mozhlivi pomilki v proyekti Pidhid IID maye i svoyi negativni storoni yaki po suti zvorotnij bik chesnot Po pershe cilisne rozuminnya mozhlivostej i obmezhen proyektu duzhe dovgij chas vidsutnye Po druge pri iteraciyah dovoditsya vidkidati chastinu ranishe zroblenoyi roboti Po tretye sumlinnist fahivciv pri vikonanni robit vse zh znizhuyetsya sho psihologichno zrozumilo adzhe nad nimi postijno tyazhiye vidchuttya sho vse odno vse mozhna bude pererobiti i polipshiti piznishe Rizni varianti iteracijnogo pidhodu realizovani v bilshosti suchasnih metodologij rozrobki RUP MSF XP Spiralna model Spiralna model angl spiral model bula rozroblena v seredini 1980 h rokiv Barri Boemom Vona zasnovana na klasichnomu cikli Deminga PDCA plan do check act Pri vikoristanni ciyeyi modeli ZA stvoryuyetsya v kilka iteracij vitkiv spirali metodom prototipuvannya Kozhna iteraciya vidpovidaye stvorennyu fragmenta abo versiyi PZ na nomu utochnyuyutsya cili i harakteristiki proyektu ocinyuyetsya yakist otrimanih rezultativ i planuyutsya roboti nastupnoyi iteraciyi Na kozhnij iteraciyi ocinyuyutsya rizik perevishennya strokiv i vartosti proyektu neobhidnist vikonannya she odniyeyi iteraciyi stupin povnoti i tochnosti rozuminnya vimog do sistemi docilnist pripinennya proyektu Vazhlivo rozumiti sho spiralna model ye ne alternativoyu evolyucijnoyi modeli modeli IID a specialno opracovanim variantom Na zhal neridko spiralnu model abo pomilkovo vikoristovuyut yak sinonim evolyucijnoyi modeli vzagali abo ne mensh pomilkovo zgaduyut yak absolyutno samostijnu model poryad z IID Vidminnoyu osoblivistyu spiralnoyi modeli ye specialna uvaga sho pridilyayetsya rizikam sho vplivaye na organizaciyu zhittyevogo ciklu i kontrolnim tochkam Boem formulyuye 10 najbilsh poshirenih za prioritetami rizikiv Deficit fahivciv Nerealistichni termini i byudzhet Realizaciya ne vidpovidaye funkcionalnosti Rozrobka nepravilnogo koristuvalnickogo interfejsu Perfekcionizm nepotribna optimizaciya ta pokrashennya detalej Bezperervnij potik zmin Brak informaciyi pro zovnishni komponenti sho viznachayut otochennya sistemi abo zaluchenih v integraciyu Nedoliki v robotah sho vikonuyutsya zovnishnimi stosovno proyektu resursami Nedostatnya produktivnist oderzhuvanoyi sistemi Rozriv u kvalifikaciyi fahivciv riznih oblastej U sogodnishnij spiralnoyi modeli viznacheno nastupnij zagalnij nabir kontrolnih tochok Concept of Operations COO koncepciya vikoristannya sistemi Life Cycle Objectives LCO cili i zmist zhittyevogo ciklu Life Cycle Architecture LCA arhitektura zhittyevogo ciklu tut mozhlivo govoriti pro gotovnist konceptualnoyi arhitekturi cilovoyi programnoyi sistemi Initial Operational Capability IOC persha versiya stvoryuvanogo produktu pridatna dlya doslidnoyi ekspluataciyi Final Operational Capability FOC gotovij produkt rozgornutij vstanovlenij i nalashtovanij dlya realnoyi ekspluataciyi PrimitkiBruks F Mifichnij lyudino misyac abo yak stvoryuyutsya programni sistemi per z angl F Bruks Sankt Peterburg Simvol Plyus 1999 304 s il Miroshnichenko E A Tehnologiyi programuvannya navchalnij posibnik E A Miroshnichenko 2 e izd ispr i dod Tomsk Izd vo Tomskogo politehnichnogo universitetu 2008 128 s Larman K Iterativna ta inkrementalna rozrobka korotka istoriya 13 zhovtnya 2016 u Wayback Machine K Larman St Bazilyu Vidkriti sistemi 2003 Orlik S