Табылған қателерді түзету үшін қадағалау бағдарламалық қамтамасыз ету ішінде зерттеудің қызықты саласы болып табылады. Қателерді қадағалап отыру үшін көптеген ашық, тегін және комерциялық құралдар әзірленді және қазіргі уақытта әзірленіп жатыр. Ұйымдар үшін қателердi түзетудiң үдерiсiн тіркеу және қадағалауын зерттеп отыруға көмектесетін және қол жетімді құрал-саймандар жинақтарының арасында ең үздік құрал таңдау үшін белгілер қажет. Бұл мақалада мен салыстырмалы зертеу үшін BugZilla, Jira, Trac, Mantis, BugTracker.Net, Gnats және Fossil-ды қолданамын. Сонымен қатар бағалау және нәтижесін алу ұшін қолданылатын қаралып шыққан құралдар үшiн жiктеуiнiң толық белгiлерiн таныстырылады.
Кіріспе
Бағдарламалық қамтамасыз ету жасалған болып саналмайды, ол бағдарламалық қамтамасыз ету үшiн қосымша модуль талап етiлетiнiні мүмкiн, немесе бар модульдың жетiлдiруi қажет екенін білдіреді, содан соң ол уақыт кешiк бағдарламалық қамтамасыз етуде қалатын кейбiр елеусiз немесе тексерiлмеген қателер құрамында бар болуы мүмкін.
Қате бағдарламалық қамтамасыз етудің кез-келген әзiрлеу кезеңінде пайда болуы мүмкiн, яғни, талаптарды талдау(RA), жобалау (SD), кодтау (SC), тестiлеу (ST), өткiзу (SI) және жүйенiң қызмет етуi (SM) кезеңдерінде. Ашық бастапқы кодты жобаларды әзiрлеуге және жобаның жетiлдiруiне өз салымын үнемi кiргiзген өңдеушiлердi шапшаң көбеюмен, жобаға жаңа қателердi енгiзудiң мүмкiндiгi бар. Жобаның веб-сайтына бағдарламалық қамтамасыз етудiң нобайларын басқару және шығаруы ұшін кескiнді басқарудың (SCM) кейбiр құралдарын пайдалана алатын күнделікті бiрнеше қателер жiберіледi. SCM құралдары қате жайындағы есеп тұралы сонымен бiрге қателердi түзетудiң жүрiсi тұралы ешқандай да ұсыну бермеуi мүмкiн. Қателердi қадағалау және есеп берудің ең жақсы жүйесiн жоспарлау және енгiзудің табанды қажеттiлiгі бар.
Әдетте, ашық бастапқы коды бар ортада, қате жiберілген кезде, оны түзетуi бойымен кез-келген адамның жұмыс бастағаны мүмкiн. Бiрақ сонымен қатар басқа адамдарда тұра сол қатені түзету жұмысын бастай алады. Сондықтан иесі, немесе жобаның модераторы жүйеде жүзеге қай шешiм асырылатынын шатасады. Ақауларды және қателерді анықтау үшiн, мақсаты бағдарламалық қамтамасыз етудiң ең жақсы жеткiзушiлерiн салыстыруы болған Business software зерттеу өткiздi. Қатенi түзету үшiн не белгiлi кесте, не қатенiң мерзiмді бекiтуiне жауапты адам/пәрмен болмайды.
Патентті бағдарламалық қамтамасыз етудiң ішінде қатенiң түзетуi кезеңдi болып өтеді, себебi әр кезеңде кәзiргi жағдайда атқарылатын жұмысқа жауапты жеке тобы бар. Бірақ ашық бастапқы коды бар жобада кез-келген адам қатені тауып, оның түзетуi бойымен жұмыс бастағаны мүмкiн. Қатенi түзету үшiн керек уақытты есептеу кезеңінде тәуелдік негiзгi мәселе болуы мүмкін.
Егер қате жүзеге асыру кезеңіне дейін табылса, оны жасаушылар командасы немесе модуль иесі сапалы түзей алады. Алайда бағдарламалық жасақтама шығарылып , қолданысқа енгізілген болса, қатені түзеу қиынға соғады. Нақты бір қатені түзей алатын жасаушыны табу модератор үшін үлкен мәселеге айналды, себебі қате туралы xабарламаның сипаттамасында толық ақпарат болмауы мумкін. Көптеген мекемелер кері байланысы бар қате туралы xабарламалар жүйесі бар немесе ондай жүйесі жоқ электронды пошталарға сенім артады, бұл қателермен электрондық кестеде немесе кез-келген құжаттарды өзгертетін бағдардамалық жасақтамаларда жұмыс жасауға болады. Модуль иесіне немесе жасаушыға қайтадан қатені және оны шешу жолдарын табу қиын болады. Есептілік пен қателер туралы xабарламалардың кіші және үлкен жобалардағы прогрессін бақылау мақсатымен шығарылған және қазіргі кезде өндірісте қолданылатын құралдар өте көп. Бізге нәтижелі, мақсатты , пайдалы және экономикалық тұрғыда нәтижелі құрал бере алатын нақты бір қателер туралы есептілік пен бақылау жүйесін таңдай өте қиын. Сауалнама жасаушылар мен қолданушылардың қатысуымен қателер туралы есептілік жүйесінде жиі кездесетін қателерді анықтау мақсатымен жүргізілді. Сонымен қатар бұрын кездескен қателер есептемесінің сапасын іздеуді үлгілеу барысында жұмыстар жүргізілді. Жақын арада ұсыну, талдау және үрдіс негізіндегі қателерді аңдитын құралдар бойынша сауалнама жүргізілді. Марко және Александр кейбір сипаттамалар негізінде шешім талын құрған.
Қателер қадағалау жүйесі (Багтрекер)
Қателерді қадағалау жүйесі, қате есеп беру және оны қадағалау прогресс үшін есеп жүйесі интерактивті веб-негізделген платформаны қамтамасыз етеді. Есеп жүйесі ортақ процесін немесе нақты өңдеу қате туралы хабарларды қамтуы мүмкін. Қате туралы ақпаратты енгізу процесі әдетте келесі элементтерді қамтуы мүмкін:
- Title (аты) — қате атауы.
- Description (сипаттамасы) — Қатенің егжей-тегжейлі сипаттамасы, соның ішінде :не, қайда, неге, қалай және қашан қате туындаған. нақты хабарлама операция кезінде пайда болған, кіріс деректер және күтілетін кірістілігі нақты жиынтығымен енгізілуі мүмкін.
- Version (нұсқа) — жобаның нұсқасы.
- Component (құрамдас) — қате табылған бағдарлама модулі.
- Screenshot/Attachment (Скриншот / өтініш) — тиісті экран суреті бір .jpg немесе .gif файл ретінде жүктеуге болады, нақты операция / шығыс / хабарлама жаулап.
- Priority (басымдық) — басым оның шұғыл болуына жатқызуға болады.
- Severity (ауырлығы) — жүйге әсер ету дәрежесі.
- Status (мәртебе) — қате ағымдағы жағдайы (дәлелденген, ашық, жаңа, жабық, т.б. …).
- Created by (автор) — қате туралы есеп жүйесінде тіркелген.
адам аты немесе идентификатор
- Assigned to (Тағайындалған) — сынақшы қатені белгілі бір тұлғаға тағайындауға болады, егер нақты адам туралы белгілі болса, мәселені шеше алса, немесе басқа менеджер тағайындай алады.
- Revision History (қайта қарау тарихы) — баяндамасында өзгерістер тарихы.
- Estimated time (болжамды уақыты)- түзету үшін уақыт. Ол, әдетте, жабық жұмыс командасының жағдайда пайдаланылады, көзі ашық ортада емес.
- Comments (Пікірлер) — қателерді анықтау кезінде пайдалы болуы мүмкін кез- келген басқа ақпарат.
Платформалардың ерекшіліктеріне қарай сыныптау.
Негізінде платформаның ерешіліктері болған салыстыру критерийлері номері екінші кестеде көрсетілген. Бұл кестедегі аспаптардың көбісі аймақтарда ашық болып келеді және бастапқы кодтары да бар. Mantis ашық бастапқы коды бар қосымшаларға жатады және де оны оңай жүктеп, қолдана беруге болады. Кейбір аспаптар тек лицензиялық түрде таратылады және онымен қолдану үшін ресми иесінің келісімі қажет. Jira-ның ақылы нұсқасы тек үш түрде бар: Standart, Proffesional және Enterprise. Нұсқа жобаның көлемі және қолдауларына қарай сөйтіп бөлінеді. Аспаптардың көбісі веб-аймақта жұмыс істейді, ал олардың алғашқы нұсқалары тек клиент-сервер аймағында қол жетімді болатын. Trac вики-аймақта құрылған болатын, яғни кез келген қолданушы оның қателерін көріп, бақылап, оларды түзеп, өзгертіп отыра алатын мүмкіндіктері бар деген сөз. Жобалардың көбісі кросс-платформасының негізінде құрылған, ал бұл жағдай — жоба кез келген компьютерге орнатыла алатын деген сөз. BugZilla және GNuts Linux жүйесінде, ал BugTracker.Net Windows жүйесінде жұмыс жасайды. Клиент қосымшалары браузерлердің негізінде құрылған, яғни әр түрлі платформаларға тәуелді емес. Веб-серверлер үшін көп аспаптар apache/tomcat -ты талап еткен, алайда BugTracker.Net тек MS/IIS-ны талап еткен. Аспаптардың көбісі MySQL-ды ақпараттар базасы ретінде қолданады, ал bugtracker.net MS-SQL Server ды, Fossil — SQLLite ты қолданады. Аспаптар код жазылып жатқан бағдарламалау тілдеріне қарай бөлінеді. Олардың көбісі C, C#, Python, Perl, Java, Net бағдарламалау тілдерінде жасалған болатын.
Басқа санаттары бойынша классификация.
Кез келген функция өзінің ішіне көптеген функцияларды кіргізе алады,олар өте маңызды,бірақ бір арнайы санаты болмауы мүмкін.Бұл қателіктерді оқшаулау, өзгерулерді болжау,қазіргі кодтың репозиториясын қарау, нұсқаларды басқару және Subversion құралы.Бұл системалардың кейбіреулерінде бұл функциялардың мүмкіндіктері бар, бірақ олар дамымаған.
Жоғарыда көрсетілген санаттар қосымша кіші санаттарға тағы бөліне алады.Бұл есеп жүйелерін және қателіктерді бақылауды жақсартуға мүмкіндік береді. Бұл құралды таңдаған кезде өте пайдалы болады ,ол қолданушы көрсеткен өлшемге сай болады. Жалпы бұл мақалада багтрекинг жүйелерінің ең маңызды қызметтері қарастырылып, критерийлар бойынша бөлінген. Негізгі және қосымша қызметтерді білу нақты бір жобаға немесе жасаушылар тобында жұмыс жасау үшін қолайлы жүйені дұрыс таңдауға мүмкіндік береді. Болащақта бұл жүйенің қызметтерінің әр қайсысына сандық баға беру мүмкіндігі пайда болу үшін жұмыстар жүргізіледі, бұл біздің таңдауымызды нақты сандармен түсіндіруге мүмкіндік береді. Сонымен қатар бағалау процессін программаның көмегімен, және де ақпаратты кесте немесе диаграмма түрінде шығару арқылы автоматтандыруға болады. Бұл таңдаудың нақты бір жүйеге түсуін көрнекті дәлелдеуге мүмкіндік береді.
Адилжанова С.А., Ғазиз Г.Г.
