Жыццёвы цыкл праграмнага забеспячэння: паняцце, стандарты, працэсы

Распрацоўка ПА немагчымая без разумення так званага жыццёвага цыкла праграм. Радавому юзэру гэта, можа быць, і не трэба ведаць, але асноўныя стандарты пажадана засвоіць (далей будзе сказана, навошта гэта трэба).

Жыццёвы цыкл праграмнага забеспячэння: што гэта такое ў фармальным разуменні?

Пад жыццёвым цыклам любога праграмнага прадукту прынята разумець час яго існавання, пачынаючы са стадыі распрацоўкі і да моманту поўнага адмовы ад выкарыстання ў абранай сферы прымянення аж да поўнага канфіскацыі прыкладання з ужытку.

Кажучы простай мовай, інфармацыйныя сістэмы ў выглядзе праграм, баз дадзеных або нават «аперацыёнак» з'яўляюцца запатрабаванымі толькі ў выпадку актуальнасці дадзеных і магчымасцяў, імі прадстаўляюцца.

Лічыцца, што вызначэнне жыццёвага цыкла ні ў якай меры не ўжываецца да тэставых прыкладанням, напрыклад, да бэта-версіях, якія з'яўляюцца самымі няўстойлівымі ў працы. Сам жа жыццёвы цыкл ПА залежыць ад мноства фактараў, сярод якіх адну з галоўных роляў гуляе асяроддзе, у якой праграма будзе выкарыстоўвацца. Аднак можна вылучыць і агульныя ўмовы, якія прымяняюцца пры вызначэнні паняцця жыццёвага цыклу.

пачатковыя патрабаванні

Як прынята лічыць, для любога праграмнага прадукту выкарыстоўваецца некалькі ўмоў, датычна яго распрацоўкі і прымянення, а менавіта:

• пастаноўка задачы;
• аналіз узаемных патрабаванняў будучага ПА да сістэмы;
• праектаванне;
• праграмаванне;
• кадаванне і кампіляцыя;
• тэставанне;
• адладка;
• укараненне і суправаджэнне праграмнага прадукту.

Распрацоўка ПА складаецца з усіх вышэйзгаданых стадый і не можа абыйсціся хоць бы без адной з іх. Але для кантролю для такіх працэсаў устаноўлены спецыяльныя стандарты.

Стандарты працэсаў жыццёвага цыкла праграмнага забеспячэння

Сярод сістэм, што прадвызначаюць ўмовы і патрабаванні, што прад'яўляюцца да такіх працэсаў, сёння можна назваць толькі тры асноўных:

• ДАСТ 34.601-90;
• ISO / IEC 12207 выпуску: 2008;
• Oracle CDM.

Для другога міжнароднага стандарту маецца расійскі аналаг. Гэта ДАСТ Р ІСО / МЭК 12207-2010, які адказвае за сістэмную і праграмную інжынерыю. Але жыццёвы цыкл праграмнага забеспячэння, апісваны ў абодвух правілах, з'яўляецца ідэнтычным па сутнасці. Тлумачыцца гэта досыць проста.

Віды ПА і апдэйты

Сучасныя інфармацыйныя сістэмы такія, што для іх ўсталёўваюцца агульнапрынятыя паняцці вобласці прымянення.

Напрыклад, ёсць сістэмныя праграмы і ўтыліты, сродкі мультымедыя, драйверы прылад, офісныя прыкладання і т. Д. Для любога тыпу праграмных прадуктаў можна вызначыць этапы жыццёвага цыкла існавання.

Для яго падаўжэння часцей за ўсё ўжываюцца сродкі абнаўлення (як для аперацыйных сістэм, так і для платформаў і прыкладнога ПА). Напэўна, не трэба тлумачыць, што любы карыстальнік кампутарнай сістэмы на аснове Windows праходзіў этап абнаўлення самой сістэмы або кампанентаў накшталт Microsoft .NET Framework або віртуальнай машыны Java.

стадыя праектавання

Зараз некалькі слоў непасрэдна аб стадыях распрацоўкі. Жыццёвы цыкл ПА першапачаткова ўключае ў сябе планаванне праекта, аналіз сістэмных і мэтавых патрабаванняў, магчымасці папярэдняга або дэталёвага праектавання, кадаванне і тэставанне, магчымасць прымянення праграм у спецыялізаваных сістэмах і т. Д.

Мадэлі жыццёвага цыкла праграмнага забеспячэння мяркуюць, што першапачаткова пастаўленая задача па стварэнні праграмнага забеспячэння павінна зводзіцца да распрацоўкі універсальных прыкладанняў або праграмных прадуктаў, якія выкарыстоўваюць пэўнае асяроддзе запуску.

распрацоўка

Сістэмы распрацоўкі ўяўляюць сабой мовы праграмавання. Праектаванне праграмнага забеспячэння на першай стадыі можа зводзіцца менавіта да гэтага.

Ці будзе гэта C + / C ++, Java, Delphi або той жа састарэлы Pascal - не гэтак важна. Пытанне складаецца ў тым, наколькі створанае прыкладанне зможа інтэгравацца ў аперацыйную сістэму і працаваць без збояў.

У гэтым сэнсе 1 жыццёвы цыкл праграмнага забеспячэння з'яўляецца часам яго тэставання ад пачатковай інсталяцыі прадукту да яго поўнага выдалення з прычыны неадпаведнасці патрабаванням сістэмы, непрацаздольнасці або немагчымасці выканання першапачаткова пастаўленых задач.

наступныя этапы

Далейшае суправаджэнне, якія вызначаюць жыццёвы цыкл праграмнага забеспячэння, зводзіцца да таго, каб вырабіць кадаваньне і атрыманне зыходнага кода прыкладання.

У выпадку яго бясплатнага (адкрытага) распаўсюджвання ўжываецца так званы сертыфікат на аснове ліцэнзіі GNU, што прадугледжвае магчымасць змены самога праграмнага прадукту па жаданні іншага карыстальніка, знаёмага з мовай праграмавання, з дапамогай якога прыкладанне стваралася.

Калі гаворка ідзе пра закрыты кодзе, можна скарыстацца ўтылітамі накшталт Disassembler. Але ў гэтым выпадку можна дамагчыся толькі раскодирования выкананага EXE-файла, а ўжо ніяк не прывязаных дынамічных бібліятэк DLL.

Але гэта тэорыя. На практыцы стадыі жыццёвага цыкла ПА ўключаюць у свой спіс куды больш элементаў. Нават самая простая экстрэмальна сітуацыя складаецца з разгляду стандартаў і фармулявання заўваг (высокаўзроўневыя патрабаванні да архітэктуры, адпаведнасць выкананага кода, сродкі і методыка верыфікацыі). Гэта і ёсць працэс жыццёвага цыкла праграмнага забеспячэння. Але тут важна разумець і некаторыя прынцыпы кіравання такімі праграмамі і сістэмамі.

асновы кіравання

Кіраванне жыццёвым цыклам праграмнага забеспячэння ажыццяўляецца на аснове разбіцця праграм на складнікі, што дае дастаткова шырокі выбар сродкаў для іх стварэння.

Ёсць і адваротны бок медаля. Выбар модуляў абмяжоўваецца распрацоўшчыкам першапачатковай платформы, на аснове якой вырабляецца праграмаванне. Вядома, калі ўзяць у разлік уніфікацыю і тыпізацыі ужывальных сродкаў распрацоўкі (асабліва шматкроць выкарыстоўваюцца модуляў), тут пытанняў няма.

А вось этапы жыццёвага цыкла праграмнага забеспячэння ў абавязковым парадку ўтрымліваюць стварэнне пратаколаў апрацоўкі дадзеных, падпраграм, стандартных бібліятэк і шмат чаго іншага.

выкарыстоўваюцца модулі

І ні адзін працэс жыццёвага цыкла праграмнага забеспячэння не абыходзіцца без выкарыстання вельмі спецыфічных кампанентаў. Сярод іх прыярытэтнымі лічацца наступныя:

• галоўны (галаўны) модуль, які адказвае за запуск праграмнага прадукту;
• кіраўнік модуль, адказны за выклік далучаюцца кампанентаў або дынамічных бібліятэк;
• функцыянальныя і сэрвісныя сродкі апрацоўкі дадзеных і дадатковыя ўтыліты.

Выкананы файл, як правіла, для Windows-сістэм прадстаўлены ў выглядзе «экзэшника». Кіраўнікі кампаненты маюць пашырэнне канфігуратараў (config.sys дачыненні да аперацыйных сістэм), дадаткова падключаюцца бібліятэкі маюць пашырэнне DLL. Сродкі кантролю і апрацоўкі функцый і налад некаторых прыкладанняў могуць выглядаць у выглядзе файлаў XML.

Яны, дарэчы, для большасці цяпер вядомых праграм мультымедыя з'яўляюцца сродкамі захавання асноўных параметраў канфігурацыі. Выкарыстанне ПА такога тыпу, вядома, з'яўляецца досыць абмежаваным, але разуменне агульных прынцыпаў працы з тымі ж медыяплэер не пашкодзіць. І вось, чаму.

Па сутнасці-то, у іх жыццёвы цыкл праграмнага забеспячэння закладзены толькі на ўзроўні тэрміну абнаўлення версіі самага прайгравальніка альбо ўсталявання кодэкаў і дэкодараў. А гукавыя і відэа транскодеры з'яўляюцца неад'емнымі атрыбутамі любой аўдыё або відэасістэмы.

Прыклад на аснове праграмы FL Studio

Першапачаткова віртуальная студыя-секвенсор FL Studio мела назву Fruity Loops. Жыццёвы цыкл ПА у яго першаснай мадыфікацыі скончыўся, але прыкладанне некалькі трансфармавалася і набыло цяперашні выгляд.

Калі казаць пра этапы жыццёвага цыкла, спачатку на стадыі пастаноўкі задачы задавалася некалькі абавязковых умоў:

• стварэнне барабаннага модуля па тыпу рытм-машын накшталт Yamaha RX, але з ужываннем one-shot-сэмплаў або секвенцый ў фармаце WAV, запісаных у студыях ужывую;
• інтэграцыя ў аперацыйныя сістэмы Windows;
• магчымасць экспарту праекта ў фарматах WAV, MP3 і OGG;
• сумяшчальнасць праектаў з дадатковым дадаткам Fruity Tracks.

На стадыі распрацоўкі былі ўжытыя сродкі моў праграмавання "Сі". Але платформа выглядала досыць прымітыўна і не давала канчатковаму карыстачу неабходнага якасці гучання.

У сувязі з гэтым, на стадыі тэставання і адладкі распрацоўнікам прыйшлося пайсці па шляху нямецкай карпарацыі Steinberg і прымяніць у патрабаваннях да асноўнага гукавога драйверу падтрымку рэжыму Full Duplex. Якасць саўнда стала вышэй і дазволіла змяняць тэмп, вышыню тону і накладваць дадатковыя FX-эфекты ў рэжыме рэальнага часу.

Завяршэннем жыццёвага цыкла гэтага ПА прынята лічыць выхад першай афіцыйнай версіі FL Studio, якая, у адрозненне ад сваіх прабацькоў, валодала ўжо інтэрфейсам паўнавартаснага сэквенсора з магчымасцю рэдагавання параметраў на віртуальным 64-канальным мікшэрны пульт з неабмежаваным даданнем аўдыё-дарожак і MIDI-трэкаў.

Прасоўванне праграмы гэтым не абмежавалася. На стадыі кіравання праектам была ўведзена падтрымка падлучэння убудоў фармату VST (спачатку другі, а потым і трэцяй версіі), у свой час распрацаванага кампаніяй Steinberg. Груба кажучы, любы віртуальны сінтэзатар, які падтрымлівае VST-host мог падлучацца да праграмы.

Нядзіўна, што неўзабаве любы кампазітар мог выкарыстаць аналагі «жалезных» мадэляў, напрыклад, поўныя камплекты гукаў некалі папулярнага Korg M1. Далей - больш. Ужыванне модуляў накшталт Addictive Drums або універсальнага плагіна Kontakt дазволіла прайграваць жывыя гукі рэальных інструментаў, запісаных з усімі адценнямі артыкуляцыі ў прафесійных студыях.

Пры гэтым распрацоўшчыкі пастараліся дамагчыся і максімальнай якасці, стварыўшы падтрымку для драйвераў ASIO4ALL, якія апынуліся на галаву вышэй рэжыму Full Duplex. Адпаведна, павысіўся і бітрэйт. На сённяшні дзень якасць экспартуемага гукавога файла можа складаць 320 кбіт / с пры частаце дыскрэтызацыі 192 кГц. А гэта прафесійны гук.

Што ж тычыцца пачатковай версіі, яе жыццёвы цыкл можна было б назваць цалкам завершаным, але такое сцвярджэнне з'яўляецца адносным, паколькі прыкладанне толькі змяніла назву і набыло новыя магчымасці.

перспектывы развіцця

Што сабой уяўляюць этапы жыццёвага цыкла праграмнага забеспячэння, ужо зразумела. Але вось пра развіццё такіх тэхналогій варта сказаць асобна.

Ня трэба казаць, што любы распрацоўнік праграмнага забеспячэння не зацікаўлены ў стварэнні мімалётнага прадукту, які ледзь ці ўтрымаецца на рынку на працягу некалькіх гадоў. У перспектыве ўсе глядзяць на доўгатэрміновае яго выкарыстанне. Дасягацца гэта можа рознымі спосабамі. Але, як правіла, практычна ўсе яны зводзяцца да выпуску абнаўленняў ці новых версій праграм.

Нават у выпадку з АС Windows такія тэндэнцыі можна заўважыць няўзброеным поглядам. Наўрад ці сёння знойдзецца хоць адзін юзэр, які выкарыстоўвае сістэмы накшталт мадыфікацый 3.1, 95, 98 або Millennium. Іх жыццёвы цыкл скончыўся пасля выхаду версіі XP. Але вось серверныя версіі на аснове тэхналогій NT ўсё яшчэ актуальныя. Нават Windows 2000 на сённяшні дзень з'яўляецца не толькі вельмі актуальнай, але і па некаторых параметрах ўстаноўкі або бяспекі нават праўзыходнай самыя новыя распрацоўкі. Тое ж самае тычыцца сістэмы NT 4.0, а таксама спецыялізаванай мадыфікацыі Windows Server 2012.

Але ў адносінах менавіта да гэтых сістэмах ўсё роўна заяўлена падтрымка на самым высокім узроўні. А вось нашумелая ў свой час Vista відавочна адчувае закат цыклу. Мала таго, што яна апынулася недапрацаванай, дык яшчэ і памылак у ёй самой і прарэхаў у яе сістэме бяспекі было столькі, што застаецца толькі здагадвацца пра тое, як можна было выпусціць на рынак праграмных прадуктаў такое незаможнае рашэнне.

Але калі казаць пра тое, што развіццё ПА любога тыпу (кіраўніка або прыкладнога) не стаіць на месцы, можна толькі канстатаваць факты. Бо сёння справа тычыцца не толькі камп'ютэрных сістэм, а і мабільных прылад, у якіх прымяняюцца тэхналогіі часцяком апярэджваюць кампутарны сектар. З'яўленне працэсарных чыпаў на аснове васьмі ядраў - чым не самы лепшы прыклад? А бо яшчэ далёка не кожны ноўтбук можа пахваліцца наяўнасцю такога «жалеза».

Некаторыя дадатковыя пытанні

Што ж тычыцца разумення жыццёвага цыкла праграмнага забеспячэння, сказаць, што ён скончыўся ў некаторы пэўны момант часу, можна вельмі ўмоўна, бо праграмныя прадукты ўсё роўна маюць падтрымку з боку распрацоўшчыкаў, іх стваралі. Хутчэй за канчатак ставіцца да састарэлым прыкладанням, якія не адказваюць патрабаванням сучасных сістэм і не могуць працаваць у іх асяроддзі.

Але нават з улікам тэхнічнага прагрэсу многія з іх ужо ў бліжэйшы час могуць апынуцца незаможнымі. Вось тады і прыйдзецца прымаць рашэнне альбо аб выпуску абнаўленняў, альбо аб поўным пераглядзе ўсёй канцэпцыі, першапачаткова закладзенай у праграмны прадукт. Адсюль - і новы цыкл, які прадугледжвае змяненне пачатковых умоў, асяроддзя распрацоўкі, тэставанні і магчымага доўгатэрміновага ўжывання ў пэўнай сферы.

Але ў кампутарных тэхналогіях сёння аддаецца перавагу развіццю аўтаматызаваных сістэм кіравання (АСК), якія прымяняюцца на вытворчасці. Нават аперацыйныя сістэмы, у параўнанні са спецыялізаванымі праграмамі, прайграюць.

Тыя ж асяроддзя на аснове Visual Basic застаюцца нашмат больш папулярнымі, чым Windows-сістэмы. А пра прыкладным ПА пад UNIX-сістэмы гаворка не ідзе наогул. Што казаць, калі практычна ўсе камунікацыйныя сеткі тых жа Злучаных Штатаў працуюць выключна на іх. Дарэчы, сістэмы накшталт Linux і Android таксама першапачаткова ствараліся менавіта на гэтай платформе. Таму, хутчэй за ўсё, у UNIX перспектыў нашмат больш, чым у астатніх прадуктаў разам узятых.

замест выніку

Застаецца дадаць, што ў дадзеным выпадку прыведзены толькі агульныя прынцыпы і этапы жыццёвага цыкла праграмнага забеспячэння. На самай справе нават зыходна пастаўленыя задачы могуць адрознівацца вельмі істотна. Адпаведна, адрозненні могуць назірацца і на астатніх стадыях.

Але асноўныя тэхналогіі распрацоўкі праграмных прадуктаў з іх наступным суправаджэннем павінны быць зразумелыя. У астатнім жа варта ўлічваць і спецыфіку стваранага ПА, і асяроддзя, у якіх яно меркавана павінна працаваць, і магчымасці праграм, якія прадстаўляюцца канчатковаму карыстальніку або вытворчасці, і многае іншае.

Да таго ж, часам жыццёвыя цыклы могуць залежаць ад актуальнасці сродкаў распрацоўкі. Калі, дапусцім, нейкі мова праграмавання састарваецца, ніхто ж не будзе пісаць праграмы на яго аснове, і ўжо тым больш - ўкараняць іх у аўтаматызаваныя сістэмы кіравання на вытворчасці. Тут ужо на першы план выходзяць нават не праграмісты, а маркетолагі, якія павінны своечасова рэагаваць на змены камп'ютэрнага рынку. І такіх спецыялістаў у свеце знойдзецца не так ужо і шмат. Высокакваліфікаваныя кадры, здольныя трымаць руку на пульсе рынку, становяцца найбольш запатрабаванымі. І менавіта яны часцяком з'яўляюцца так званымі «шэрымі кардыналамі», ад якіх залежыць поспех або пройгрыш пэўнага праграмнага прадукту ў сферы IT.

Хай яны не заўсёды разумеюць сутнасць праграмавання, затое выразна здольныя вызначыць мадэлі жыццёвага цыкла праграмнага забеспячэння і працягласці часу іх ужывання, зыходзячы з сусветных тэндэнцый у гэтай галіне. Эфектыўны менеджмент часцяком дае больш адчувальныя вынікі. Ды хоць бы PR-тэхналогіі, рэклама і т. Д. Можа нейкае прыкладанне карыстачу і не трэба, затое пры ўмове яго актыўнага афішавання юзэр ўсталюе яго. Гэта ўжо, так бы мовіць, падсвядомы ўзровень (той жа эфект 25-га кадра, калі інфармацыя закладваецца ў свядомасць юзера незалежна ад яго самога).

Вядома, такія тэхналогіі ў свеце з'яўляюцца забароненымі, аднак многія з нас нават не здагадваюцца пра тое, што яны ўсё роўна могуць выкарыстоўвацца і ўздзейнічаць на падсвядомасць вызначаным спосабам. Чаго толькі варта «замбіяваньня» навінавымі каналамі або інтэрнэт-сайтамі, не кажучы ўжо пра ўжыванне больш магутных сродкаў, накшталт ўздзеяння інфрагуку (такое было ўжыта ў адной опернай пастаноўцы), з прычыны чаго чалавек можа адчуваць страх або неадэкватныя эмоцыі.

Вяртаючыся да праграмнага забеспячэння, варта дадаць, што некаторыя праграмы пры запуску выкарыстоўваюць гукавы сігнал, які прываблівае ўвагу юзера. І, як паказваюць даследаванні, такія прыкладання аказваюцца больш жыццяздольнымі, у параўнанні з іншымі праграмамі. Натуральна, павялічваецца і жыццёвы цыкл ПА, без розніцы, якая функцыя на яго ўскладзена першапачаткова. І гэтым, на жаль, карыстаюцца многія распрацоўшчыкі, што выклікае сумневы ў законнасці такіх метадаў.

Але не нам судзіць аб гэтым. Магчыма, у бліжэйшы час будуць распрацаваны сродкі, якія вызначаюць такія пагрозы. Пакуль гэта толькі тэорыя, але, як лічаць некаторыя аналітыкі і эксперты, да практычнага прымянення засталося зусім няшмат. Калі ўжо ствараюць копіі нейронавых сетак чалавечага мозгу, то што казаць?