Процес на проверка и валидиране на дизайна

Проверка на дизайна

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

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

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

Валидиране на дизайна

Проверката доказва вътрешна съгласуваност. Валидацията задава по-трудния въпрос дали спецификацията е описала правилния продукт на първо място.

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

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

Банерът по-долу обозначава двете половини на дейността, както обикновено са представени в проектните записи.

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

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

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

Разлика между проверка на дизайна и валидиране

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

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

Процес на проверка на дизайна

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

Идентификация и подготовка:

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

планиране:

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

Развиванеping:

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

Екзекуция:

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

Доклади:

• Тази дейност се извършва в края на всяка фаза на изпълнение на проверката.
• Докладът за проверка на проекта предоставя подробно обобщение на резултатите от проверката, включително управление на конфигурацията, резултатите за всеки тип тестване и проблемите, открити по време на дейността по проверка.
• Проверка на дизайна tracДоклад за изправност се създава между изискванията и съответните резултати от тестовете, за да се потвърди, че всички изисквания са тествани и че са записани съответните резултати.
• Всяко несъответствие се документира и се разглежда по подходящ начин.
• RevПрегледите се извършват след завършване на дейността по проверка на проекта и резултатите се одобряват официално.

Процес на валидиране на дизайна

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

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

Пример

Един кратък разработен пример прави разграничението конкретно.

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

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

Предимства на валидирането и проверката на дизайна

Непрекъснатото изпълнение на двете дейности, а не като преход в края, е това, което води до предимствата, посочени по-долу.

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

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

Въпроси и Отговори