11. Жизненный цикл ПО и процессы верификации.

Верификация ПО – процесс определения выполняет ли ПО предъявляемые к нему требования. Верификация является неотъемлемой частью разработки ПО и в конечном итоге обеспечивает отсутствие ошибок в работе ПО, под которыми мы будем понимать невыполнение ПО заданных функций с определенными характеристиками качества, оговоренных в нормативно технических документах.

Артефактами проекта будем называть продукты проекта, порождаемые в нем в процессе разработки конечного продукта – ПО. Верификация – это последовательный процесс, проходящий через все процессы разработки, а не разовая операция. Однократный контроль качества уже конечного продукта, например, при тестировании – это неправильная практика. Она в большинстве случаев приводит к большому объему переделок и доработок в конце разработки, когда они стоят дорого. При этом возможна ситуация, когда программа внешне сделана правильно и работает без ошибок, но делает не то, что надо.

Эти ошибки в алгоритме возникают часто при передаче требований от одного разработчика другому. Давно замечено, что ошибки часто возникают «на стыках» между людьми, совместно работающими в одном проекте, при неточных и неполных формулировках, взаимном недопонимании и неполной передаче ими информации друг другу. Рис 3 хорошо иллюстрирует этот процесс

Поэтому и нужна верификация, как процесс контроля однозначности интерпретации артефактов и результатов «на стыках», в процессе которой необходимо проверять соответствие одних, создаваемых в ходе инженерной разработки артефактов – технологических процессов, документов, моделей, программного кода другим, созданным ранее, и используемым в качестве исходных данных для проверяемых. Этот последовательный процесс начинается с ТЗ на систему или ТЗ на ПО.

Верификация также определяет соответствие процессов разработки, документов, ПО стандартам.

В частности, верификация определяет соответствие между нормами стандартов, описанием требований – техническим заданием на ПО, проектными решениями и архитектурой ПО, полученным кодом ПО пользовательской документацией. Тестирование ПО, отмеченное как этапы жизненного цикла, являются также методом верификации. Но одним тестированием верификация не исчерпывается Верификация должна проводиться для всех артефактов, создаваемых при разработке ПО.

При этом организационными артефактами являются структура работ, план-графики работ, планы обеспечения качества, планы испытаний, описание системы качества, описания процессов и процедур выполнения отдельных работ.

12. Тестирование, верификация, валидация. Различие в понятиях. V образная модель жизненного цикла ПО

Тестирование часто трактуется, как проверка правильности программной реализации. При другой форме организации работ, когда разработчик программы и алгоритма – одно и то же лицо тестирование ПО -

процесс, охватывающий и проверку алгоритма с использованием модели внешней среды.

14

Действительно, для организации работ, когда разработку ПО ведет конечный пользователь, тестирование ПО - это конечно не только проверка правильности программной реализации заданного алгоритма функционирования. Проверяется также и сам алгоритм с точки зрения правильного выполнения всех задач системы, с точки зрения отсутствия алгоритмических ошибок.

Для организации работ, когда ПО разрабатывается в рамках аутсортинга разработчиком ПО, не являющимся разработчиком системы, разработчик ПО действительно может придерживаться позиции проверки только правильности программной реализации, уповая на правильность полученного ТЗ. Обнаружение алгоритмических ошибок может вызывать у него затруднения. В этих случаях верификация артефактов проекта ПО совместно с разработчиком системы и её заказчиком весьма актуальна.

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

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

V образная модель жизненного цикла ПО содержит процессы двух видов: основные процессы разработки(левая ветвь) и процессы верификации(правая ветвь), являющиеся обратными связями к основным процессам. Укрупненно можно эти процессы отобразить на схеме рис.2.

Основными методами верификации кроме динамического тестирования ПО путем его исполнения на ЦВМ являются:

экспертизы, проводимые одновременно двумя разработчиками двух документов - предшествующим и последующим. Техника проведения таких экспертиз специально разработана. Часто процесс

[Введите текст]

верификации принимает форму согласования обоими разработчиками этих документов (артефактов).

статический анализ кода с проверкой правил корректности его написания,

формальные методы анализа правильности моделей программ, записанных на специальных

языках моделирования, обеспечивающих этот процесс.

Впоследнем случае доказанная правильность модели программы не говорит о правильности самой программы. Поэтому последний метод несмотря на давние и широкие обсуждения в практике программирования распространения не получил .

Рис3. Иллюстрация к вопросу правильности передачи информации между разработчиками и заказчиком.

16

13. Спиральная модель ЖЦ ПО.

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

Главная задача как можно быстрее достичь работоспособного ПО, активизируя тем самым процесс уточнения и дополнения требований. Это так называемая спиральная модель ЖЦ ПО, изображенная на рис. 4.

Эта схема ЖЦ ПО для торопливых разработчиков и для ПО, некачественные первые версии которого допустимы по функциональному назначению ПО. В действительности «тяжелые технологии» разработки по каскадному жизненному циклу также имеют итеративный характер проектирования ПО по стадиям формирования требований, технических предложений, эскизного проекта и т.п., предусмотренных при проектировании СТС соответствующими стандартами проектирования.

Эти технологии ориентированны на средний уровень квалификации программистов, требуют документирования всех работ, детального и долгосрочного планирования и в глазах многих являются избыточно усложненными.

[Введите текст]