Теоретические основания экспертизы программного продукта на соответствие ТЗ и ГОСТ 📚

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

Центральным понятием выступает требование. Требование в рамках экспертизы программного продукта на соответствие ТЗ и ГОСТ понимается как вербально или формально закреплённое предписание, которое задаёт обязательное, допустимое или запрещённое состояние программного продукта, его функции, структуру, поведение, интерфейсы, ограничения или показатели качества. Требования различаются по источнику происхождения: одни из них порождаются техническим заданием как договорным документом, другие — государственными стандартами как нормативными документами. Совпадение этих источников по содержанию не является автоматическим; техническое задание может конкретизировать, усиливать или уточнять стандартные положения, но не должно им противоречить.

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

Третий блок — теория доказательства. Эксперт не может ограничиваться утверждением о соответствии или несоответствии; он обязан предъявить проверяемые основания. Доказательство в экспертизе программного продукта строится на трёх типах свидетельств: документальных, инструментальных и аналитических. Документальные свидетельства фиксируют требования и заявленные характеристики. Инструментальные свидетельства получаются в результате измерений, тестов, трассировки, статического и динамического анализа. Аналитические свидетельства формируются путём логического сопоставления первых и вторых. Теоретическая модель доказательства требует, чтобы каждое утверждение эксперта допускало повторную проверку независимым специалистом на той же совокупности исходных данных.

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

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

Объект экспертизы также имеет сложную структуру. Им выступает не только исполняемый код, но и совокупность артефактов: исходные тексты, конфигурационные файлы, описания интерфейсов, эксплуатационная документация, результаты сборки, журналы испытаний. Государственные стандарты задают требования к документированию, терминологии, составу характеристик и форме представления сведений о программном продукте. Техническое задание задаёт требования к конкретному изделию. Пересечение этих двух множеств требований образует предметное поле экспертизы.

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

📌 Таким образом, теоретические основания экспертизы программного продукта на соответствие ТЗ и ГОСТ образуют связную систему понятий: требование, источник требования, эталон, фактическое состояние, свидетельство, прослеживаемость, расхождение, квалификация, вывод. Эта система служит основой для всех последующих частей, в которых рассматриваются нормативная база, методология сопоставительного анализа, инструментальные средства, документирование, типовые несоответствия и организация процесса.

Нормативная база и классификация требований ТЗ и ГОСТ в экспертизе программного продукта ⚖️

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

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

Государственные стандарты в рассматриваемой области образуют многоуровневую совокупность.

1. Первый уровень составляют основополагающие стандарты, устанавливающие терминологию, классификацию, общие требования к программным средствам и их документированию.
2. Второй уровень образуют стандарты на отдельные виды деятельности, включая стадии создания, испытания и сопровождения программных средств.
3. Третий уровень — стандарты, определяющие требования к качеству, надёжности, безопасности и совместимости.
4. Четвёртый уровень — стандарты, регламентирующие состав и содержание документов, включая техническое задание, программу и методику испытаний, руководство пользователя, описание программы.

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

Отдельного внимания заслуживает проблема полноты и непротиворечивости требований. Техническое задание может содержать пробелы, а стандарт — допускать различные толкования. Экспертиза программного продукта на соответствие ТЗ и ГОСТ обязана различать три ситуации: требование отсутствует, требование присутствует, но неоднозначно, требование присутствует и однозначно. В первой ситуации эксперт не вправе домысливать требование; он фиксирует его отсутствие как фактор неопределённости. Во второй ситуации эксперт формулирует допустимые толкования и проверяет продукт по каждому из них. В третьей ситуации проверка ведётся по буквальному содержанию требования.

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

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

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

📌 Таким образом, нормативная база экспертизы программного продукта на соответствие ТЗ и ГОСТ представляет собой двухконтурную систему, а классификация требований — инструмент, позволяющий привести разнородные предписания к единому виду, пригодному для сопоставительного анализа.

Методология сопоставительного анализа программного продукта с ТЗ и ГОСТ 🔬

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

Всё это напрямую связано с таким направлением, как экспертиза программного продукта на соответствие ТЗ.

Первый этап — построение эталонной модели. Эталонная модель формируется на основе технического задания и применимых стандартов. Она включает перечень требований с идентификаторами, указанием источника, формы выражения и метода проверки. Эталонная модель не является копией технического задания; она представляет собой результат его аналитической переработки. В ходе переработки выявляются дублирующие требования, требования с неопределёнными терминами, требования, отсылающие к другим документам. Каждое требование приводится к форме, допускающей проверку.

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

Третий этап — сопоставление моделей. Сопоставление ведётся по каждому требованию отдельно. Результатом сопоставления является одна из четырёх оценок: полное соответствие, частичное соответствие, несоответствие, невозможность проверки. Полное соответствие фиксируется, когда фактическая характеристика удовлетворяет требованию при всех предусмотренных условиях. Частичное соответствие фиксируется, когда требование выполняется лишь при части условий или лишь для части предусмотренных режимов. Несоответствие фиксируется, когда фактическая характеристика противоречит требованию. Невозможность проверки фиксируется, когда отсутствуют необходимые свидетельства или метод проверки неприменим.

Четвёртый этап — квалификация расхождений. Каждое частичное соответствие и каждое несоответствие подлежит квалификации по источнику, существенности и устранимости. По источнику расхождения делятся на связанные с продуктом, связанные с техническим заданием, связанные со стандартом, связанные с методом проверки. По существенности выделяются критические, значительные и малозначительные расхождения. По устранимости различаются расхождения, устранимые изменением продукта, устранимые изменением документации, неустранимые в рамках данного продукта.

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

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

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

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

📌 Таким образом, методология сопоставительного анализа в рамках экспертизы программного продукта на соответствие ТЗ и ГОСТ представляет собой последовательность преобразований: требование — эталонная модель — фактическая модель — сопоставление — квалификация — вывод. Каждый этап имеет собственные правила и собственные формы фиксации результатов.

Инструментальные средства и процедуры проверки соответствия ТЗ и ГОСТ 🛠️

Инструментальные средства экспертизы программного продукта на соответствие ТЗ и ГОСТ подразделяются на три класса: средства анализа исходного текста, средства анализа исполняемого поведения и средства анализа документации. Каждый класс имеет собственные возможности и собственные ограничения, а их совместное применение обеспечивает полноту свидетельств.

Именно в этом проявляется практическое значение такого направления, как экспертиза программного продукта на соответствие ТЗ.

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

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

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

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

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

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

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

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

📌 Таким образом, инструментальные средства и процедуры проверки образуют исполнительный контур экспертизы программного продукта на соответствие ТЗ и ГОСТ. Их согласованное применение позволяет получить совокупность свидетельств, достаточную для обоснованных выводов по каждому требованию.

Документирование результатов экспертизы программного продукта на соответствие ТЗ и ГОСТ 📄

Документирование результатов является неотъемлемой частью экспертизы программного продукта на соответствие ТЗ и ГОСТ. Документ экспертизы выполняет три функции: фиксирующую, доказательную и коммуникативную. Фиксирующая функция состоит в закреплении исходных данных, процедур и результатов. Доказательная функция состоит в предъявлении оснований для каждого вывода. Коммуникативная функция состоит в передаче результатов заинтересованным сторонам в форме, допускающей однозначное понимание.

Эти положения важны для понимания того, что представляет собой экспертиза программного продукта на соответствие ТЗ.

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

Каждый вывод в документе должен удовлетворять требованию прослеживаемости. Это означает, что вывод содержит ссылку на требование, ссылку на свидетельство и ссылку на метод проверки. Такая тройная привязка позволяет проверить вывод без обращения к устным пояснениям эксперта. Если вывод не может быть привязан к свидетельству, он не включается в документ.

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

Терминология документа должна быть единообразной. Один и тот же объект обозначается одним и тем же термином на протяжении всего документа. Если термин заимствован из стандарта, указывается источник заимствования. Если термин введён экспертом, приводится его определение. Единообразие терминологии снижает риск неоднозначного понимания и облегчает проверку документа.

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

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

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

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

📌 Таким образом, документирование результатов в рамках экспертизы программного продукта на соответствие ТЗ и ГОСТ представляет собой систему, в которой каждый элемент связан с методологией, а каждый вывод опирается на прослеживаемые свидетельства.

Типовые несоответствия ТЗ и ГОСТ и способы их квалификации 📋

Типовые несоответствия, выявляемые в ходе экспертизы программного продукта на соответствие ТЗ и ГОСТ, могут быть сгруппированы по нескольким основаниям. Группировка позволяет унифицировать квалификацию и снизить влияние субъективного усмотрения на итоговые оценки.

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

Вторая группа — параметрические несоответствия. К ним относятся выход за пределы заданных значений, неверные единицы измерения, несоответствие диапазонов, несоответствие точности. Параметрические несоответствия квалифицируются с учётом допустимых отклонений, если такие отклонения заданы техническим заданием или стандартом.

Третья группа — интерфейсные несоответствия. К ним относятся несоответствие форматов обмена данными, несоответствие протоколов взаимодействия, несоответствие состава полей, несоответствие кодировок. Интерфейсные несоответствия квалифицируются как значительные, если нарушают взаимодействие с внешними системами, и как малозначительные, если затрагивают второстепенные элементы.

Четвёртая группа — документарные несоответствия. К ним относятся отсутствие обязательного документа, несоответствие структуры документа стандарту, несоответствие терминологии, неполнота описания. Документарные несоответствия квалифицируются с учётом того, насколько они затрудняют эксплуатацию и сопровождение продукта.

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

Шестая группа — несоответствия, связанные с неопределённостью требований. К ним относятся ситуации, когда требование технического задания неоднозначно, когда стандарт допускает несколько толкований, когда требование отсылает к документу, недоступному эксперту. Такие несоответствия не квалифицируются как дефекты продукта; они фиксируются как факторы неопределённости, влияющие на полноту вывода.

Квалификация несоответствия включает четыре шага.

1. Первый шаг — установление источника требования.
2. Второй шаг — установление фактического состояния.
3. Третий шаг — установление характера расхождения.
4. Четвёртый шаг — установление степени существенности.

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

Существенность расхождения определяется по трём критериям: влияние на основные функции, влияние на взаимодействие с внешней средой, влияние на сопровождение. Если расхождение затрагивает все три критерия, оно квалифицируется как критическое. Если два — как значительное. Если один — как малозначительное. Критерии применяются единообразно ко всем расхождениям.

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

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

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

Организация процесса экспертизы программного продукта на соответствие ТЗ и ГОСТ 🗂️

Организация процесса экспертизы программного продукта на соответствие ТЗ и ГОСТ охватывает последовательность этапов, распределение работ и формы фиксации результатов. Организационная схема подчинена методологии и обеспечивает её практическое применение.

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

Следующий этап — сбор исходных данных. На этом этапе эксперт получает техническое задание, стандарты, документацию, исходные тексты, исполняемую конфигурацию, доступ к среде испытаний. Полнота исходных данных оценивается сразу; недостающие данные запрашиваются до начала проверки. Если данные недоступны, это фиксируется как ограничение экспертизы.

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

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

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

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

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

Формы фиксации результатов едины для всех этапов. Используются журналы, матрицы, перечни, протоколы. Единые формы позволяют сопоставлять результаты разных этапов и разных экспертиз. Экспертиза программного продукта на соответствие ТЗ и ГОСТ выигрывает в качестве, когда организационные формы устойчивы и не зависят от конкретного исполнителя.

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

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

📌 Таким образом, организация процесса экспертизы программного продукта на соответствие ТЗ и ГОСТ представляет собой упорядоченную последовательность этапов, обеспеченную едиными формами фиксации и контролем качества на каждом шаге.

Заключение ✅

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

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

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

Во второй части была рассмотрена нормативная база экспертизы программного продукта на соответствие ТЗ и ГОСТ. Было установлено, что она образует двухконтурную систему, включающую техническое задание как договорный и одновременно технический документ и государственные стандарты как нормативные документы. Техническое задание занимает особое положение: оно не является нормативным правовым актом, но приобретает обязательную силу для сторон договора после согласования и утверждения.

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

В третьей части была изложена методология сопоставительного анализа программного продукта с ТЗ и ГОСТ. Была описана последовательность этапов: построение эталонной модели, построение фактической модели, сопоставление моделей, квалификация расхождений, формирование вывода. Каждый этап имеет собственный вход, выход и критерий завершённости. Результатом сопоставления является одна из четырёх оценок: полное соответствие, частичное соответствие, несоответствие, невозможность проверки.

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

В четвёртой части были рассмотрены инструментальные средства и процедуры проверки соответствия ТЗ и ГОСТ. Средства были разделены на три класса: средства анализа исходного текста, средства анализа исполняемого поведения и средства анализа документации.

1. Первый класс включает статические анализаторы, средства измерения метрик, средства поиска шаблонов и средства построения графов зависимостей.
2. Второй класс включает тестовые среды, средства трассировки, профилировщики, средства мониторинга ресурсов и средства имитации внешних воздействий.
3. Третий класс включает средства проверки структуры документов, терминологии и полноты.

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

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

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

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

Существенность определяется по трём критериям: влияние на основные функции, влияние на взаимодействие с внешней средой и влияние на сопровождение. Устранимость расхождения определяется по характеру требуемого изменения. Было подчёркнуто, что типовые несоответствия не исчерпывают всех возможных ситуаций, но задают ориентиры для квалификации и обеспечивают единообразие оценок.

В седьмой части была изложена организация процесса экспертизы программного продукта на соответствие ТЗ и ГОСТ. Были описаны этапы процесса: подготовка, сбор исходных данных, построение эталонной модели, сбор свидетельств, сопоставление и квалификация, оформление результатов. Распределение работ внутри экспертной группы строится по направлениям: анализ требований, анализ исходного текста, анализ исполняемого поведения, анализ документации, квалификация расхождений. Формы фиксации результатов едины для всех этапов: журналы, матрицы, перечни, протоколы. Контроль качества включает проверку полноты, прослеживаемости, непротиворечивости и воспроизводимости. Завершение процесса оформляется выпуском итогового документа и передачей его заказчику вместе с приложениями, содержащими свидетельства.

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

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

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

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