Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Оқытылған мамандардың өзара сараптамасы
Peer review by trained individuals
Бағдарламалық жасақтаманы әзірлеудегі сараптама, яғни тексеру – бұл оқытылған мамандардың нақты белгіленген процесті пайдаланып, кемшіліктерді іздеу үшін кез келген жұмыс нәтижесін өзара сараптауын білдіреді. Мұндай сараптаманы Майкл Фаганның құрметіне Фаган сараптамасы деп те атауға болады, ол өте танымал бағдарламалық қамтамасыз етуді тексеру процесін жасаған адам.
Inspection in software engineering, refers to peer review of any work product by trained individuals who look for defects using a well defined process. An inspection might also be referred to as a Fagan inspection after Michael Fagan, the creator of a very popular software inspection process.
Кіріспе
Тексеру – бағдарламалық жасақтама жобаларындағы ең көп кездесетін тексеру түрлерінің бірі. Тексерудің мақсаты – ақауларды анықтау. Көбінесе бағдарламалық қамтамасыз ету талаптарының сипаттамалары және сынақ жоспарлары тексеріледі. Тексеру кезінде жұмыс өнімі тексеру үшін таңдалып алынады және жұмыс өнімін тексеру үшін инспекциялық отырысқа команда жиналады. Отырысты жүргізу үшін модератор тағайындалады. Әрбір инспектор жұмыс өнімін оқып, кездесуге дайындалады, сондай-ақ әрбір ақауды белгілейді. Тексеру кезінде ақау – инспектордың оны мақұлдауына кедергі келтіретін жұмыс өнімінің кез келген бөлігі. Мысалы, егер команда бағдарламалық қамтамасыз ету талаптарының сипаттамасын тексеріп жатса, әрбір ақау – инспектор келіспейтін құжаттағы мәтін болады.
An inspection is one of the most common sorts of review practices found in software projects. The goal of the inspection is to identify defects. Commonly inspected work products include software requirements specifications and test plans. In an inspection, a work product is selected for review and a team is gathered for an inspection meeting to review the work product. A moderator is chosen to moderate the meeting. Each inspector prepares for the meeting by reading the work product and noting each defect. In an inspection, a defect is any part of the work product that will keep an inspector from approving it. For example, if the team is inspecting a software requirements specification, each defect will be text in the document which an inspector disagrees with.
Тексеру процесі
Тексеру процесі 1970 жылдардың ортасында әзірленді, кейін кеңейтіліп, өзгертілді. Процестің басталу критерийлері болуы керек, олар тексеру процесін бастауға дайын екенін анықтайды. Бұл аяқталмаған жұмыс өнімдерінің тексеру процесіне түсуіне кедерес жасайды. Басталу критерийлері, мысалы, "Документ орфографиялық тұрғыдан тексерілді" сияқты пунктілерді қамтитын тізім болуы мүмкін. Тексеру процесінің кезеңдері: жоспарлау, жалпы көрініс кездесуі, дайындық, тексеру кездесуі, түзету және қадағалау. Дайындық, тексеру кездесуі және түзету кезеңдері қайталанылуы мүмкін. Жоспарлау: Тексеруді модератор жоспарлайды. Жалпы көрініс кездесуі: Автор жұмыс өнімінің контекстін сипаттайды. Дайындық: Әрбір тексеруші жұмыс өнімін мүмкін болатын кемшіліктерді анықтау үшін зерттейді. Тексеру кездесуі: Осы кездесуде оқушы жұмыс өнімін бөлік-бөлік етіп оқиды, ал тексерушілер әрбір бөліктің кемшіліктерін көрсетеді. Түзету: Автор тексеру кездесуінен алынған іс-шара жоспарларына сәйкес жұмыс өніміне өзгерістер енгізеді. Қадағалау: Автор енгізген өзгерістердің дұрыс екеніне көз жеткізу үшін тексеріледі. Процесс, модератор белгіленген шығу критерийлеріне сәйкес келгенде аяқталады. "Тексеру" термині бағдарламалық жасақтаманы жобалау жобасының орындалуы мен сәтті аяқталуын қамтамасыз ететін процестің ең маңызды элементтерінің бірін білдіреді.
The inspection process was developed in the mid 1970s and it has later been extended and modified. The process should have entry criteria that determine if the inspection process is ready to begin. This prevents unfinished work products from entering the inspection process. The entry criteria might be a checklist including items such as "The document has been spell checked". The stages in the inspections process are: Planning, Overview meeting, Preparation, Inspection meeting, Rework and Follow up. The Preparation, Inspection meeting and Rework stages might be iterated. Planning: The inspection is planned by the moderator. Overview meeting: The author describes the background of the work product. Preparation: Each inspector examines the work product to identify possible defects. Inspection meeting: During this meeting the reader reads through the work product, part by part and the inspectors point out the defects for every part. Rework: The author makes changes to the work product according to the action plans from the inspection meeting. Follow up: The changes by the author are checked to make sure everything is correct. The process is ended by the moderator when it satisfies some predefined exit criteria. The term inspection refers to one of the most important elements of the entire process that surrounds the execution and successful completion of a software engineering project.
Тексерудің рөлі
Тексеру кезінде келесі рөлдер қолданылады. Автор: Тексеріліп жатқан жұмыс өнімін жасаған адам. Модератор: Бұл инспекцияны жетекшісі. Модератор тексеруді жоспарлайды және оны үйлестіреді. Оқырман: Құжаттарды біреу-біреулеп оқып шығатын адам. Басқа инспекторлар одан кейін ақауларды көрсетеді. Хаттамашы: Тексеру кезінде табылған ақауларды тіркеп алатын адам. Инспектор: Жұмыс өнімін қарап, мүмкін ақауларды анықтайтын адам.
During an inspection the following roles are used. Author: The person who created the work product being inspected. Moderator: This is the leader of the inspection. The moderator plans the inspection and coordinates it. Reader: The person reading through the documents, one item at a time. The other inspectors then point out defects. Recorder/Scribe: The person that documents the defects that are found during the inspection. Inspector: The person that examines the work product to identify possible defects.
Кодты қайта қарау
Кодты қайта қарау – бұл команданың кодтың үлгісін тексеріп, кез келген кемшіліктерді жоятын арнайы тексеру түрі. Кодты қайта қарау барысында кемшілік – бұл талаптарды дұрыс іске асырмайтын, бағдарламашының күткендей жұмыс істемейтін немесе қате болмаса да, жақсартуға болатын (мысалы, оқуды жеңілдетуге немесе өнімділігін арттыруға болатын) код бөлігі. Командаларға қателерді табуға және түзетуге көмектесуден өзге, кодты қайта қарау кодты қарастырып жатқан бағдарламашылардың білімін арттыруға және жас дамытушыларға жаңа бағдарламалау техникаларын үйренуге де пайдалы.
A code review can be done as a special kind of inspection in which the team examines a sample of code and fixes any defects in it. In a code review, a defect is a block of code which does not properly implement its requirements, which does not function as the programmer intended, or which is not incorrect but could be improved (for example, it could be made more readable or its performance could be improved). In addition to helping teams find and fix bugs, code reviews are useful both for cross training programmers on the code being reviewed and for helping junior developers learn new programming techniques.
Теңдестердің шолуы
Пірлердің аралық тексерулер бағдарламалық жасақтамадағы ақауларды ертерек анықтау және бағдарламалық өнімдер туралы білу үшін индустриядағы ең жақсы тәжірибе саналады. Пірлердің аралық тексерулері бағдарламалық өнімдерді зерделеу және тексеруден тұрады және бағдарламалық өнімді жасау қызметтерінің маңызды бөлігі болып табылады. Ұйымдастырылған білім, дағдылар және мінез-құлықтар жиынтығы пірлердің аралық тексерулерін тиімді жүзеге асыруға көмектеседі. Пірлердің аралық тексерулерінің элементтері: құрылымдалған тексеру процесі, өнім сапасының стандартты тізімдері, қатысушылардың анықталған рөлдері, формалар мен есептер. Бағдарламалық өнімдерді тексеру – пірлердің аралық тексерулерінің ең қатаң түрі және ақауларды анықтау үшін осы элементтерді толыққанды пайдаланады. Бағдарламалық өнімдерді зерделеу өндірушіге өнім туралы толық түсінік алуға және қатысушылар арасында келісімге жетуге көмектесу үшін элементтерді таңдап қолданады. Шығарылған нәтижелер пірлердің аралық тексерулерінің үлкен инвестициялық кіріс әкелетінін көрсетеді, бұл үдемел оқыту және ерте ақауларды анықтау арқылы қол жеткізіледі. Ең жақсы нәтижелер үшін пірлердің аралық тексерулері ұйым ішінде саясат пен процедураны әзірлеу, мамандар мен менеджерлерді оқыту, өлшемдерді анықтау және деректер базасын құру, сондай-ақ қолдау инфрақұрылымын ұстау бойынша нақты бағдарлама арқылы енгізіледі.
Peer reviews are considered an industry best practice for detecting software defects early and learning about software artifacts. Peer Reviews are composed of software walkthroughs and software inspections and are integral to software product engineering activities. A collection of coordinated knowledge, skills, and behaviors facilitates the best possible practice of Peer Reviews. The elements of Peer Reviews include the structured review process, standard of excellence product checklists, defined roles of participants, and the forms and reports. Software inspections are the most rigorous form of Peer Reviews and fully utilize these elements in detecting defects. Software walkthroughs draw selectively upon the elements in assisting the producer to obtain the deepest understanding of an artifact and reaching a consensus among participants. Measured results reveal that Peer Reviews produce an attractive return on investment obtained through accelerated learning and early defect detection. For best results, Peer Reviews are rolled out within an organization through a defined program of preparing a policy and procedure, training practitioners and managers, defining measurements and populating a database structure, and sustaining the roll out infrastructure.