Бағдарламалық өнімді жеткізілімнен кейін өзгерту

Кіріспе

Бағдарламалық өнімнің жеткізілгеннен кейінгі өзгертілуі

Бағдарламалық өнімге техникалық қызмет көрсету – бағдарламалық өнімнің жеткізілгеннен кейінгі өзгертілуі. Бағдарламалық жасақтаманы күтіп-ұстау көбінесе жаңа әзірлеуге қарағанда біліктілігі төмен және аз сыйақылы деп есептеледі. Сондықтан, ол аутсорсинг немесе офшорлық қызметтерге жиі тапсырылады. Әдетте, бағдарламалық жасақтаманы әзірлейтін команда, оны күтіп-ұстайтын командадан өзгеше болады. Әзірлеушілер кодты оңай күтіп-ұстау үшін жазуға ынталы емес. Бағдарламалық жасақтама көбінесе толыққанды жеткізілмейді және техникалық қызмет көрсету тобы түзетуге тиіс қателерді әрқашан қамтиды. Бағдарламалық жасақтаманы күтіп-ұстау бастапқыда жаңа мүмкіндіктерді дамытуды қамтиды, бірақ өнім өмірлік циклының соңына жақындағанда күтіп-ұстау ең төменгі деңгейге дейін қысқартылады, содан кейін өнім тоқтатылғанға дейін толығымен тоқтатылады. Әрбір күтіп-ұстау циклі әдетте клиенттен келетін өзгерту туралы өтінішпен басталады. Бұл өтініш бағаланады және оны жүзеге асыру туралы шешім қабылданса, бағдарламашы өзгерісті енгізу алдында қолданыстағы кодты оның қалай жұмыс істейтінін түсіну үшін зерттейді. Қолданыстағы мүмкіндіктер сақталғанын және қажетті жаңа мүмкіндіктер қосылғанын тексеру көбінесе күтіп-ұстау құнының көп бөлігін құрайды. Бағдарламалық жасақтаманы күтіп-ұстау, шығындардың көп бөлігін құрағанына қарамастан, бағдарламалық өмірлік циклдің басқа кезеңдері сияқты жақсы зерттелмеген. 1980 жылдардан бері түсініктер айтарлықтай өзгерген жоқ. Бағдарламалық қамтамасыз етуді техникалық қызмет көрсету алдын алу шаралары немесе реактивті шаралар, сондай-ақ мүмкіндіктерді қосу немесе қолданыстағы мүмкіндіктерді сақтау мақсатында жүргізіледі, осыған байланысты бірнеше түрге бөлуге болады.

Тарих

1970-ші жылдардың басында компаниялар бағдарламалық қамтамасыз етуді күтіп ұстауды жеке инженерлер тобымен бөліп, бағдарламалық қамтамасыз етуді дамыту топтарын қолдау міндеттерінен босатуды бастады. 1972 жылы Р. Г. Кэннинг "Құрақтау айсбергі" атты еңбегін жариялады, онда ол бағдарламалық қамтамасыз етуді күтіп ұстау – бұл қолданыстағы жүйе қосымша дереккөз ретінде қарастырылатын бағдарламалық қамтамасыз етуді дамытудың жалғасы екенін айтты. Бағдарламалық қамтамасыз етуді күтіп ұстау саласы содан бері көп өзгерген жоқ. Бір 21-ші ғасырлық жаңалық – компаниялар қасақана толық емес бағдарламалық жасақтаманы шығарып, оны жарияланғаннан кейін аяқтауды жоспарлауда. Мұндай өзгерістер және функционалдықты кеңейтетін басқа да өзгерістер көбінесе техникалық қызмет көрсету орнына бағдарламалық жасақтаманың эволюциясы деп аталады.

Бағдарламалық жасақтаманың өмірлік циклі

Сынақтан өткізуге және сапаны қамтамасыз етуге қарамастан, дерлік барлық бағдарламалық жасақтамада жүйе күтілгендей жұмыс істемейтін қателер болады. Бұл қателер анықталғанда оларды жою үшін шығарылымнан кейінгі техникалық қолдау қажет. Көптеген бағдарламалық жасақтамалар – бұрыннан бар коммерциялық (COTS) және ашық кодты бағдарламалық жасақтама компоненттері мен арнайы жазылған кодтың үйлесімінен тұрады. COTS және ашық кодты бағдарламалық жасақтама әдетте уақыт өте келе жаңартылып отырады, бұл техникалық қолдау жүктемесін азайтуға мүмкіндік береді, бірақ осы бағдарламалық жасақтама компоненттеріне енгізілген өзгерістерді түпкілікті өнімге бейімдеу қажет. Бағдарламалық жасақтаманы әзірлеу, белгілі талаптарды орындауға бағытталған болса, бағдарламалық жасақтаманы күтіп-ұстау оқиғалармен – мысалы, клиенттердің өтініштерімен немесе қателердің анықталуымен шақырылады. Оның басты мақсаты – бағдарламалық жасақтаманың пайдалылығын сақтау, әдетте талаптардың өзгеруіне байланысты. Егер бағдарламалық жасақтаманы дамыту өмірлік циклының бір бөлігі ретінде қарастырылса, онда техникалық қолдау – циклдің соңғы және әдетте ең ұзақ кезеңі болып табылады, ол ресурстардың шамамен 75 пайызын құрайды, ал бастапқы даму кезеңіне бар болғаны 25 пайыз жұмсалады. Басқа бағалаулар бойынша техникалық қолдауға кеткен шығындар одан да жоғары, өмірлік циклдің 80-90 пайызына дейін жетеді. Тағы да бір модельдер бағдарламалық жасақтаманы дамытудан бөлек қарастырады, оны бағдарламалық жасақтаманы күтіп-ұстау өмірлік циклының (SMLC) бір бөлігі ретінде қарастырады. SMLC модельдері әдетте кодты түсінуді, оны өзгертуді және қайтадан тексеруді қамтиды.

Рұқсат етуден техникалық қызмет көрсетуге дейін пайдалану мерзімінің соңына дейін

Бағдарламалық жасақтама көбінесе толық емес күйде жеткізіледі. Дамушылар өнімді уақыт немесе қаржы таусылғанша сынақтан өткізеді, себебі олар жетілмеген өнім үшін уақыт пен бюджеттің шегінен асып түсуден гөрі аз жазаға ұшырайды. Дамудан техникалық қолдау тобына өту жиі тиімсіз болады, себебі белгілі мәселелердің тізімі немесе техникалық қолдау тобы қайта жасайтын тексеру сынақтары болмайды. Жеткізілгеннен кейін, даму тобының мүшелері басқа жұмысқа ауыстырылуы немесе қолжетімсіз болуы мүмкін. Техникалық қолдау тобына өнімді іске қосылғаннан кейін алғашқы жыл ішінде техникалық қолдау көрсету және даму кезінде қалған қателерді түзету үшін қосымша ресурстар қажет болады. Бастапқыда бағдарламалық жасақтама жетілдіру кезеңінен өтуі мүмкін. Жаңа мүмкіндіктер клиенттердің пікірлеріне сәйкес қосылады. Бір кезде компания функционалдық жақсартулардың пайдалы болмайтынына шешім қабылдап, қолдауды қателерді түзетумен және шұғыл жаңартулармен шектеуі мүмкін. Тәжірибе жетіспеуі немесе бағдарламалық жасақтаманың ескіруіне байланысты архитектураның нашарлауы салдарынан өзгерістерді енгізу күрделі және қымбатқа түседі. Егер өнім енді қолдау көрсетілмесе және тіпті осы шектеулі жаңартуларды алмаса, кейбір сатушылар өнімнен қашықтау мүмкіндігінше ұзақ уақыт бойы кіріс табуға тырысады. Соңында бағдарламалық жасақтама нарықтан алынып тасталады, бірақ оны пайдалану жалғастырылуы мүмкін. Осы процесте бағдарламалық жасақтама ескірген жүйеге айналады.

Өзгеріс циклі

Өзгеріс циклының бірінші қадамы – клиенттен өзгеріс туралы сұрауды қабылдау және оны проблеманы растау және өзгерісті іске асыруды шешу үшін талдау. Бұл үшін бірнеше бөлімнің қатысуы қажет болуы мүмкін; мысалы, маркетинг тобы өзгерістің бизнесті дамытуға көмектесетінін бағалауға көмектесе алады. Бағдарламалық жасақтаманы әзірлеудегі жұмыс көлемін бағалау қиын мәселе, тіпті техникалық қолдауға қатысты өзгеріс сұраулары үшін де, бірақ егер ол тым қымбат немесе орындалуы мүмкін болмаса, сұрау қабылдамау ықтимал. Егер сұрауды іске асыру туралы шешім қабылданса, оны жоспарланған шығарылымға қосып, іске асыруға болады. Кодты түсіну, оны өзгерту алдындағы маңызды қадам. Түсіну жылдамдығы код базасының және бағдарламашының біліктілігіне байланысты. Кодтау конвенцияларын сақтау, мысалы, функциялар мен айнымалылардың мақсатына сәйкес келетін анық атауларды қолдану түсінуді жеңілдетеді. Шартты циклдарды тек код бірнеше рет орындалуы мүмкін болған жағдайда ғана қолдану және ешқашан орындалмайтын кодты жою түсінуді арттыра алады. Тәжірибелі бағдарламашылар кодтың жалпы мағынасын оңай түсінеді. Бұл процесті жеделдету үшін кейде бағдарламалық визуализация қолданылады. Кодқа кез келген тәсілмен өзгеріс енгізілуі мүмкін. Бір жағынан, код құжаттамасын жаңартуға жеткілікті уақыт берілмей, жылдам түзетулер жасау жиі кездеседі. Екінші жағынан, қатаң құрылымдалған итеративті жақсарту жоғары деңгейдегі талаптар құжатын өзгертуден басталып, өзгерістер жүйенің төменгі деңгейлеріне таратылуы мүмкін. Өзгерістерге көбінесе кодты қайта құру (функционалдылықты өзгертпей құрылымын жақсарту) және реструктуризация (құрылым мен функционалдылықты бір уақытта жақсарту) кіреді. Коммерциялық бағдарламалық жасақтамадан айырмашылығы, ашық бастапқы кодты бағдарламалық жасақтамадағы өзгеріс циклдары көбінесе кодтау мен сынақтан тұрады, құжаттама минималды болады. Ашық бастапқы кодты бағдарламалық жасақтама жобалары код базасын түсіну және қателерді тиімді түзету үшін пошта тізімдеріне және көптеген қатысушыларға сенеді. Техникалық қолдаудың қосымша қиындығы – кодқа енгізілген әрбір өзгеріс жаңа қателерге немесе күтпеген салдарларға әкелуі мүмкін, бұл түзетулердің тағы бір циклын қажет етеді. Қауіпсіздікке маңызды кодты техникалық қолдау ресурстарының көп бөлігі сынаққа жұмсалуы мүмкін, себебі кез келген өзгеріс енгізілген жағдайда бүкіл бағдарламалық жасақтаманы қайта растау қажет. Қайта растау кодты қарауды, бірлік тесттерінің ішінен таңдалған бөлігімен регрессиялық сынақтарды, интеграциялық және жүйелік сынақтарды қамтуы мүмкін. Сынақтың мақсаты – бұрынғы функционалдылық сақталғанын және жаңа функционалдылық қосылғанын тексеру.

The first step in the change cycle is receiving a change request from a customer and analyzing it to confirm the problem and decide whether to implement the change. This may require input from multiple departments; for example, the marketing team can help evaluate whether the change is expected to bring more business. Software development effort estimation is a difficult problem, including for maintenance change requests, but the request is likely to be declined if it is too expensive or infeasible. If it is decided to implement the request, it can be assigned to a scheduled release and implemented. Understanding existing code is an essential step before modifying it. The rate of understanding depends both on the code base as well as the skill of the programmer. Following coding conventions such as using clear function and variable names that correspond to their purpose makes understanding easier. Use of conditional loop statements only if the code could execute more than once, and eliminating code that will never execute can also increase understandability. Experienced programmers have an easier time understanding what the code does at a high level. Software visualization is sometimes used to speed up this process. Modification to the code may take place in any way. On the one hand, it is common to haphazardly apply a quick fix without being granted enough time to update the code documentation. On the other hard structured iterative enhancement can begin by changing the top level requirements document and propagating the change down to lower levels of the system. Modification often includes code refactoring (improving the structure without changing functionality) and restructuring (improving structure and functionality at the same time). Unlike commercial software, free and open source software change cycles are largely restricted to coding and testing, with minimal documentation. Open source software projects instead rely on mailing lists and a large number of contributors to understand the code base and fix bugs efficiently. An additional problem with maintenance is that nearly every change to code will introduce new bugs or unexpected ripple effects, which require another round of fixes. Testing can consume the majority of maintenance resource for safety critical code, due to the need to revalidate the entire software if any changes are made. Revalidation may include code review, regression testing with a subset of unit tests, integration tests, and system tests. The goal of the testing is to verify that previous functionality is retained, and the new functionality has been added.

Сақтау мүмкіндігі

Сақтауға қабілеттілік – бұл бағдарламалық жасақтаманың қолданыстағы функционалдығын бұзбай, оны оңай өзгертуге мүмкіндік беретін сапасы. ISO/IEC 14764 спецификациясына сәйкес, бағдарламалық жасақтаманы шығару алдында сақтауға қабілеттілігін қамтамасыз етуге бағытталған жұмыс, бағдарламалық жасақтаманы күтіп ұстаудың бір бөлігі болып есептеледі. Көптеген бағдарламалық жасақтаманы әзірлеу ұйымдары сақтауға қабілеттілікті ескермейді, тіпті ол ұзақ мерзімді шығындарды арттыратынын білсе де. Техникалық қарыз, бағдарламалаушылардың, көбінесе жалқаулықтан немесе мерзімді ұстауға асығудан, кодтарына сақтауға қабілеттілікті енгізудің орнына жылдам және сапасыз шешімдерді таңдағанда туындайды. Бағдарламалық жасақтаманы әзірлеуге жұмсалатын күш-жігерді бағалаудағы қателіктер, дамуға бөлінетін ресурстардың жеткіліксіздігіне алып келеді. Маңызды аспектінің бірі – бұл өзгерістердің қолданыстағы функционалдықты бұзатынын анықтай алатын, автоматтандырылған бағдарламалық жасақтаманы тестілеудің көп болуы. Сақтауға қабілеттілікпен байланысты қиындық – көптеген бағдарламалық жасақтама инженерлік курстары оған жеткілікті мән бермейді және нақты және өзгермейтін талаптары бар, бір рет тапсырылатын тапсырмалар береді. Бағдарламалық жасақтаманы жасау курстары, нақты әлемде кездесетіндей күрделі жүйелерді қамтымайды. Бағдарламалық жасақтаманы күтіп ұстауға жауапты емес екенін білетін инженерлер, оны сақтауға қабілетті етуге ынталы болмайды.

Жұмыс күші

Техникалық қызмет көрсету бағдарламалық жасақтама инженерлері үшін көбінесе сыйсыз жұмыс саналады, сондықтан мұндай жұмысқа тағайындалған инженерлер жұмыстан кетуге бейім. Ол бағдарламалық жасақтаманы жасаудағы ұқсас жұмыстан төмен жалақы төлейді. Бұл міндет көбінесе уақытша жұмысшыларға немесе біліктілігі төмен қызметкерлерге жүктеледі, бірақ техникалық қызмет көрсету инженерлері әдетте әзірлеушілерге қарағанда ересектеу болады, себебі олар ескірген технологиялармен жақсы таныс болуы керек. Компаниялар техникалық қызмет көрсету үшін жеке командалар құрды, бұл осы жұмысты басқа компанияға аутсорсингке беруге алып келді, ал жиырма бірінші ғасырдың басында кейде бастапқы компанияның бөлігі ретінде немесе жеке ұйым ретінде әлемнің басқа бөлігіне офшоринг жасады. Офшоринг жасаудың себептері: еңбек құнының төмендігін пайдалану, тәулік бойы қолдау көрсетуге мүмкіндік беру, әзірлеушілерге уақыт қысымын азайту және қолдауды өнім нарығына жақындату. Офшорингтің кемшіліктері – уақыт белдеуі, ұйымдық байланыстың жоқтығы және мәдени айырмашылықтар сияқты факторлар тудыратын байланыс кедергілері. Көптеген жұмыс берушілер техникалық қызмет көрсетуді төмен біліктілікпен атқарылатын жұмыс және офшорингке ең қолайлы бағдарламалық жасақтаманы әзірлеу кезеңі деп есептесе де, ол клиенттермен тығыз байланыс пен жылдам жауап беруді қажет етеді, ал осы байланыс қиындықтары осы екеуіне де кедергі келтіреді. 2008 жылы АҚШ-та жұмыс істейтін 1,3 миллион бағдарламалық жасақтама инженерлері мен бағдарламалаушылардың шамамен 900 мыңы техникалық қызметпен айналысты, және офшоринг көбейгеніне қарамастан бұл көрсеткіш өсіп келеді.

Зерттеу

Бағдарламалық жасақтаманы әзірлеу ресурстарының басым бөлігін жұмсағанмен, техникалық қолдау – бағдарламалық жасақтаманы әзірлеудің ең аз зерттелген кезеңі. Әдебиеттердің көп бөлігі бастапқыда-ақ қолдауға ыңғайлы кодты қалай жасауға болатынына назар аударған, ал инженерлерді қолдауды басымдыққа қоюға ынталандыруға көбінесе аз мән берілген. 2020 жылға дейін, техникалық қолдауды азайту мақсатында кодты қайта құруға арналған автоматтандырылған шешімдер және машиналық оқыту арқылы қолдауға қабілеттілікті бағалау белсенді зерттеу саласы болып табылады.