Цикъл на живот на софтуера: концепция, стандарти, процеси

Разработването на софтуер е невъзможно без разбиране на така наречения жизнен цикъл на програмите. Това може да не е необходимо да бъде известно на обикновен потребител, но е желателно да се овладеят основните стандарти (ще бъде допълнително обсъдено защо това е необходимо).

Жизнен цикъл софтуер: какво е в официалния смисъл?

При жизнения цикъл на всеки софтуер продукт е обичайно да се разбира времето на съществуването му, като се започне от етапа на разработване и до момента на пълен отказ да се използва в избраната област на приложение, докато приложението бъде напълно премахнато от ежедневната употреба.

По-просто казано, информационните системи под формата на програми, бази данни или дори "операционни системи" са търсени, само ако данните и възможностите, предоставени от тях, са уместни.

Смята се, че дефиницията на жизнения цикъл по никакъв начин не се прилага за тестови приложения, например за бета версии, които са най-нестабилни в работата. Самият жизнен цикъл на софтуера зависи от много фактори, сред които една от основните роли играе средата, в която програмата ще бъде използвана. Възможно е обаче да се идентифицират общите условия, използвани при определяне на концепцията за жизнения цикъл.

Първоначални изисквания

Както обикновено се смята, за всеки софтуерен продукт се използват няколко условия по отношение на неговото разработване и приложение, а именно:

• изявление на проблема;
• анализ на взаимните изисквания на бъдещия софтуер към системата;
• дизайн;
• програмиране;
• кодиране и компилация;
• тестване;
• отстраняване на грешки;
• внедряването и поддръжката на софтуера.

Разработването на софтуер се състои от всички горепосочени етапи и не може да се направи без поне един от тях. Но за контрола за такива процеси се установяват специални стандарти.

Стандарти за процесите на жизнения цикъл на софтуера

Сред системите, които предопределят условията и изискванията за такива процеси, днес има само три основни:

• GOST 34.601-90;
• ISO / IEC 12207: 2008;
• Oracle CDM.

За втория международен стандарт има руски аналог. Това е GOST R ISO / IEC 12207-2010, отговарящ за системното и софтуерното инженерство. Но описаният в двата правила софтуерния жизнен цикъл е идентичен по същество. Това се обяснява просто.

Видове софтуер и актуализации

Съвременните информационни системи са такива, че установяват общоприети понятия в областта на приложение.

Например, има системни програми и комунални услуги, мултимедийни инструменти, драйвери за устройства, офис приложения и др. За всеки вид софтуерни продукти можете да определите етапите от жизнения цикъл на съществуването.

За подновяване най-често се използват инструменти за надстройване (както за операционни системи, така и за платформи и приложни програмни продукти). Вероятно не е необходимо да се обяснява, че всеки потребител на компютърна система, базирана на Windows, е претърпял етап от актуализирането на самата система или на компоненти като Microsoft .NET Framework или Java виртуалната машина.

Дизайн етап

Сега няколко думи директно за етапи на развитие. Животният цикъл на софтуера първоначално включва планиране на проекта, анализ на системните и целевите изисквания, възможност за предварително или детайлно проектиране, кодиране и тестване, възможност за използване на програми в специализирани системи и т.н.

Моделите на жизнения цикъл на софтуера предполагат, че първоначалната задача за създаване на софтуер трябва да бъде разработването на универсални приложения или софтуерни продукти, които използват специфична среда за стартиране.

дизайн

Системите за разработка са езици за програмиране. Дизайнът на софтуера в първия етап може да бъде намален до това.

Независимо дали става въпрос за C + / C ++, Java, Delphi или за същия остарял Pascal, това не е толкова важно. Въпросът е доколко създаденото приложение може да се интегрира в операционната система и да работи без провал.

В този смисъл един жизнен цикъл на софтуерното тестване е по време на първоначалната инсталация на продукта до неговото пълно премахване поради несъответствие на системните изисквания, неизползваеми или невъзможност за изпълнение на задачите първоначално.

Следващите стъпки

Допълнителната поддръжка, която определя жизнения цикъл на софтуера, се свежда до кодиране и получаване на изходния код на приложението.

В случай на свободен (отворен) на разпространението на т.нар сертификата се прилага въз основа на лиценза GNU, че дава възможност за промени в самия софтуер по искане на потребителя, запознати с езика за програмиране, с който е създаден на заявлението.

Ако това е затворен код, можете да използвате помощни програми като Disassembler. Но в този случай можете да постигнете само декодиране на изпълнимия EXE файл и със сигурност не свързаните динамични DLL файлове.

Но това е теория. На практика стадиите от жизнения цикъл на софтуера включват много повече елементи в техния списък. Дори и най-простата симулирана ситуация се състои в изследване на стандарти и формулиране на забележки (архитектурни изисквания на високо ниво, спазване на изпълнимия код, средства и методика за проверка). Това е жизненият цикъл на софтуера. Но е важно да се разберат някои принципи за управление на такива програми и системи.

Основи на управлението

Управлението на жизнения цикъл на софтуера се осъществява въз основа на разделянето на програмите на компоненти, което дава доста широк набор от инструменти за тяхното създаване.

Също така има и недостатък на монетата. Изборът на модулите е ограничен до разработчика на първоначалната платформа, въз основа на която се извършва програмирането. Разбира се, ако вземем предвид обединяването и въвеждането на използваните инструменти за разработка (особено модулите за повторно използване), няма въпроси.

Но етапите на жизнения цикъл на софтуера задължително включват създаването на протоколи за обработка на данни, подпрограми, стандартни библиотеки и много други.

Използвани модули

И нито един процес на жизнения цикъл на софтуера не е завършен без използването на много специфични компоненти. Сред тях се считат за приоритетни следните:

• главният (главен) модул, отговорен за стартирането на софтуера;
• контролен модул, отговарящ за извикване на приложените компоненти или динамични библиотеки;
• функционални и сервизни инструменти за обработка на данни и допълнителни комунални услуги.

Изпълнимият файл, по правило, за Windows-системите се представя под формата на "exeshnika". Контролните компоненти имат разширение на конфигуратора (config.sys за операционни системи), а допълнителните библиотеки имат DLL разширение. Могат да изглеждат контролите и обработката на функциите и настройките на някои приложения XML файлове.

Между другото, за повечето познати мултимедийни програми те са средство за запазване на основните конфигурационни параметри. Използването на софтуер от този тип, разбира се, е доста ограничено, но разбирането на общите принципи на работа със същите медийни плейъри няма да навреди. И затова.

Всъщност в тях жизненият цикъл на софтуера се поставя само на нивото на актуализираната версия на самия играч или инсталирането на кодеци и декодери. И аудио и видео транскодерите са основните атрибути на всяка аудио или видео система.

Пример, базиран на FL Studio

Първоначално виртуалният студиен секвентор FL Studio е наречен Fruity Loops. Цикълът на живот на софтуера в неговата основна модификация изтече, но приложението беше до известна степен трансформирано и придобиваше настоящата форма.

Ако говорим за етапите на жизнения цикъл, най-напред на етапа на задачата бяха определени няколко задължителни условия:

• създаването на барабан машини барабан тип модул като Yamaha RX, но с един изстрел-проба или последователност в WAV формат, записан на живо в студиото;
• интегриране в операционни системи Windows;
• възможността за експортиране на проекта във форматите WAV, MP3 и OGG;
• Проекти за съвместимост с допълнително приложение Fruity Tracks.

На етапа на разработка бяха използвани програмните езици C. Но платформата изглеждаше доста примитивна и не даваше на крайния потребител необходимото качество на звука.

В тази връзка, по време на разработчиците на провеждане на тестовете и отстраняване на грешки трябваше да тръгнат по пътя на германската корпорация Стайнберг и прилага по отношение на основните изисквания за поддръжка на звук драйвер за режим на пълен дуплекс. Качеството на звука стана по-високо и позволи да се промени темпото, терена и да се наслагват допълнителни FX ефекти в реално време.

Завършването на жизнения цикъл на софтуера, се счита за изхода на първата официална версия на FL Studio, който, за разлика от техните предци, е бил пълноправен секвенатор интерфейс с възможност за промяна на настройките на виртуалната 64-канален смесителен пулт с неограничен добавяне на аудио записи и Миди-писти.

Насърчаването на програмата не спираше там. На етапа на управлението на проекта беше представена поддръжка за свързване на VST приставки (първа, втора и трета версия), разработена от Steinberg по това време. Грубо казано, всеки виртуален синтезатор, който поддържа VST-хост, може да се свърже с програмата.

Не е изненадващо, че скоро всеки композитор може да използва аналози на "железни" модели, например, пълни звуци от някога популярния Korg M1. Още - още. Използването на модули като Addictive Drums или универсалния plug-in "Contact" направи възможно възпроизвеждането на живи звуци от истински инструменти, записани с всички нюанси на артикулацията в професионалните студия.

В същото време разработчиците се опитаха да постигнат максимално качество, като създадоха поддръжка за драйверите ASIO4ALL, които се оказаха по-високи от режима Full Duplex. Съответно, битрейтът също се е увеличил. Към днешна дата качеството на изнесения аудио файл може да е 320 kbit / s при честота на изваждане от 192 kHz. И това е професионален звук.

Що се отнася до първоначалната версия, неговият жизнен цикъл би могъл да се нарече напълно завършен, но подобно твърдение е относително, защото приложението само промени своето име и спечели нови възможности.

Перспективи за развитие

Какви са етапите от жизнения цикъл на софтуера, вече е ясно. Но заслужава да се спомене разработването на такива технологии поотделно.

Не е необходимо да казваме, че всеки разработчик на софтуер не се интересува от създаването на краткотрайни продукти, които е малко вероятно да останат на пазара в продължение на няколко години. В дългосрочен план всеки гледа на дългосрочната му употреба. Това може да се постигне по много начини. Но, като правило, почти всички от тях се свеждат до пускането на актуализации или нови версии на програми.

Дори и в случая на Windows OS такива тенденции могат да се видят с невъоръжено око. Малко вероятно е днес да има поне един потребител, използващ системи като модификации 3.1, 95, 98 или Millennium. Техният жизнен цикъл приключи след пускането на версията на XP. Но версиите на сървъри, базирани на NT технологии, все още са уместни. Дори досега Windows 2000 не само е много подходящ, но и за някои параметри на инсталацията или сигурността, дори надминавайки последните новости. Същото важи и за системата NT 4.0, както и специализираната модификация на Windows Server 2012.

Но във връзка с тези системи подкрепата на най-високо ниво все още се обявява. Но сензационното в своето време Vista очевидно преживява цикъла на залез. Не само това, че е недовършена, така че все още и грешки в себе си, и недостатъци в системата за сигурност е толкова много, че можем само да гадаем за това как е било възможно да се пусне софтуерно решение, е несъстоятелно.

Но ако говорим за факта, че разработването на софтуер от всякакъв тип (мениджър или приложение) не стои неподвижно, можем само да посочим фактите. В края на краищата днес не само компютърните системи, но и мобилните устройства, където технологиите често надминават компютърния сектор. Появата на чипове на процесора на базата на осем ядра - не е ли най-добрият пример? И все пак не всеки лаптоп може да се похвали с такъв "желязо".

Някои допълнителни въпроси

Що се отнася до разбирането на жизнения цикъл на софтуера, да кажем, че то завършва в даден момент, то може да бъде много произволно, защото софтуерните продукти все още имат подкрепа от разработчиците, които ги създадоха. По-скоро, краят се отнася за наследствени приложения, които не отговарят на изискванията на съвременните системи и не могат да работят в тяхната среда.

Но дори и като се има предвид техническият прогрес, много от тях вече в близко бъдеще може да се окажат несъстоятелни. Тогава трябва да решите дали да пуснете актуализации или напълно да преразгледате цялата концепция, първоначално вградена в софтуера. Следователно - и нов цикъл, който включва промяна на първоначалните условия, средата за развитие, тестване и възможна дългосрочна употреба в определена област.

Но в компютърната технология днес се предпочита разработването на автоматизирани системи за управление (ACS), които се използват в производството. Дори операционните системи, в сравнение със специализираните програми, губят.

Същите среди, базирани на Visual Basic, остават много по-популярни от системите, базирани на Windows. И приложен софтуер за UNIX-системи изобщо не говори. Какво да кажа, ако почти всички комуникационни мрежи на едни и същи щати работят изключително за тях. Между другото, на тази платформа бяха създадени системи като Linux и Android. Поради това, най-вероятно UNIX има много повече перспективи, отколкото други продукти, комбинирани.

Вместо общо

Остава да се добави, че в този случай са дадени само общи принципи и етапи от жизнения цикъл на софтуера. Всъщност дори първоначалните задачи могат да се различават значително. Съответно, различията могат да бъдат наблюдавани в останалите етапи.

Но основните технологии за разработване на софтуерни продукти с тяхната последваща поддръжка трябва да са ясни. В противен случай трябва да вземете предвид спецификата на създадения софтуер и средата, в която се очаква да работи, както и възможностите на програмите, предоставяни на крайния потребител или продукцията, и много други.

В допълнение, понякога жизнените цикли могат да зависят от уместността на инструментите за развитие. Ако например някой език за програмиране изчезне, никой няма да напише програми, базирани на него, а още повече - да ги въведе в автоматизирани системи за управление в производството. Тук дори и програмистите не излизат на преден план, а търговци, които трябва да реагират своевременно на промените в компютрите. И няма толкова много специалисти по света. Висококвалифицираният персонал, способен да държи ръка на пулса на пазара, става най-търсеното. И те често са т.нар. "Сиви кардинали", на които зависи успехът или загубата на определен софтуер в ИТ областта.

Нека те не винаги разбират същността на програмирането, но те ясно са в състояние да определят моделите на жизнения цикъл на софтуера и продължителността на тяхното прилагане, въз основа на глобалните тенденции в тази област. Ефективното управление често води до по-осезаеми резултати. Да, най-малко PR технологии, реклама и т.н. Може би някои приложения не се нуждаят от потребител, но ако е активно рекламирано, потребителят ще го инсталира. Това вече е, така да се каже, подсъзнателното ниво (същия ефект от 25-ия кадър, когато информацията се съхранява в съзнанието на потребителя, независимо от себе си).

Разбира се, такива технологии в света са забранени, но много от нас дори не предполагат, че те все още могат да бъдат използвани и да повлияят на подсъзнанието по определен начин. Това само е "зомби" новинарски канали или интернет сайтове, да не говорим за използването на по-мощни инструменти, като например излагането на инфразвук (това се прилага в една и съща продукция опера), така че човек може да изпита страх или неподходящи емоции.

Връщайки се към софтуера, струва си да се добави, че някои програми използват звуков сигнал при стартиране, привличайки вниманието на потребителя. И както показват проучванията, подобни приложения са по-жизнеспособни в сравнение с други програми. Естествено, цикълът на живот на софтуера се увеличава, без значение коя функция е присвоена на него първоначално. И това, за съжаление, се използва от много разработчици, което поражда съмнения относно валидността на такива методи.

Но ние не трябва да преценяваме това. Може би в близко бъдеще ще бъдат разработени инструменти, които определят такива заплахи. Досега това е само теория, но според някои анализатори и експерти малкото остава в практическо приложение. Ако вече създавате копия на невронните мрежи на човешкия мозък, какво да кажете?