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

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

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

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

Изображението по-долу представя процеса на валидиране на дизайна.

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

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

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

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

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

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

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

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

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

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

планиране:

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

Разработване:

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

Екзекуция:

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

Доклади:

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

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

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

Пример

• Нека вземем пример за простия продукт, водоустойчив часовник.
• Документът с изискванията за продукта може да гласи, че „Часовникът трябва да е водоустойчив по време на плуване“.
• Спецификацията на дизайна може да гласи „Часовникът трябва да функционира дори ако потребителят плува за продължително време“.
• Резултатите от тестовете трябва да потвърдят, че часовникът трябва да отговаря на тези изисквания, в противен случай се правят итерации на редизайна, докато не удовлетвори изискването.

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

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