🟦 Экспертиза программного продукта на соответствие ТЗ

Теоретико-методологические основания экспертизы существенности недостатков программного продукта 📚

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

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

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

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

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

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

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

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

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

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

Структура экспертного исследования существенности недостатков включает несколько последовательных этапов.

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

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

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

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

Критерии и квалиметрические шкалы существенности недостатков программного продукта 💻

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

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

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

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

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

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

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

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

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

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

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

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

Процедурная модель экспертизы существенности недостатков программного продукта 🗂️

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

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

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

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

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

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

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

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

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

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

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

Доказательная база и фиксация результатов экспертизы существенности недостатков программного продукта 📄

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

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

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

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

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

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

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

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

Фиксация результатов экспертизы осуществляется в форме экспертного заключения. Заключение должно содержать следующие разделы:

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

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

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

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

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

Инструментальные средства поддержки экспертизы существенности недостатков программного продукта 🛠️

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

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

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

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

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

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

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

Применение инструментальных средств имеет свои ограничения.

1. Никакое средство не может полностью заменить эксперта: инструменты лишь предоставляют данные, интерпретация которых остается за человеком.
2. Инструменты могут давать ложные срабатывания, то есть указывать на проблемы, которые в действительности не являются дефектами.
3. Инструменты могут пропускать дефекты, которые не обнаруживаются автоматически.

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

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

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

Типология экспертных ситуаций и разрешение спорных случаев существенности недостатков программного продукта 💻

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

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

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

Верификация и валидация экспертных заключений о существенности недостатков программного продукта 📄

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение ✅

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

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

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

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

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

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

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

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

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

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