🟩 Экспертиза соответствия ПО техническому заданию

Раздел 1. Понятие и сущность экспертизы соответствия ПО техническому заданию

Подраздел 1.1. Определение и предмет исследования

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

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

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

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

Подраздел 1.2. Место экспертизы в системе оценки программных продуктов

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

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

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

Подраздел 1.3. Отличие экспертизы соответствия от смежных видов исследований

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

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

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

Раздел 2. Правовые и договорные основания экспертизы соответствия ПО техническому заданию

Подраздел 2.1. Техническое задание как документ, определяющий предмет проверки

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

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

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

Подраздел 2.2. Договорные условия, влияющие на экспертизу

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

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

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

Подраздел 2.3. Процессуальные аспекты использования экспертного заключения

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

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

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

Раздел 3. Случаи, в которых требуется экспертиза соответствия ПО техническому заданию

Подраздел 3.1. Приемка программного обеспечения от разработчика

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

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

Подраздел 3.2. Споры о качестве и функциональности

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

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

Подраздел 3.3. Проверка соответствия заявленным характеристикам

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

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

Подраздел 3.4. Оценка полноты выполнения работ

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

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

Подраздел 3.5. Выявление ошибок и дефектов в программном коде

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

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

Подраздел 3.6. Оценка производительности и надежности

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

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

Подраздел 3.7. Проверка безопасности программного обеспечения

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

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

Подраздел 3.8. Иные случаи, требующие профессиональной оценки

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

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

Раздел 4. Методы и технологии экспертизы соответствия ПО техническому заданию

Подраздел 4.1. Анализ технического задания и проектирование сценариев использования

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

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

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

Подраздел 4.2. Сопоставление результатов тестирования с требованиями задания

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

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

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

Подраздел 4.3. Иные виды тестирования и анализа

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

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

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

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

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

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

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

Раздел 5. Этапы проведения экспертизы соответствия ПО техническому заданию

Подраздел 5.1. Предварительная консультация и определение целей

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

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

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

Подраздел 5.2. Сбор и изучение технического задания, проектной документации, исходного кода

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

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

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

Подраздел 5.3. Проведение тестирования и анализа программного обеспечения

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

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

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

Подраздел 5.4. Анализ полученных результатов и выявление несоответствий

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

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

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

Подраздел 5.5. Формирование экспертного заключения и предоставление отчета заказчику

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

Заключение должно быть мотивированным. Каждый вывод должен опираться на результаты исследования, которые описаны в заключении. Недопустимо делать выводы, которые не следуют из исследовательской части. Недопустимо также скрывать результаты, которые противоречат выводам. Экспертиза соответствия ПО техническому заданию требует полноты и честности. Если в ходе исследования были получены результаты, которые не укладываются в общую картину, они должны быть отражены в заключении с объяснением их значения.

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

Раздел 6. Кейсы из практики экспертизы соответствия ПО техническому заданию

Подраздел 6.1. Кейс первый: приемка корпоративной системы управления задачами

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

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

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

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

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

Подраздел 6.2. Кейс второй: спор о функциональности мобильного приложения

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

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

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

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

Подраздел 6.3. Кейс третий: проверка полноты выполнения работ по разработке учетной системы

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

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

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

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

Подраздел 6.4. Кейс четвертый: выявление дефектов в программном обеспечении медицинского назначения

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

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

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

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

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

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

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

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

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

Подраздел 6.6. Кейс шестой: проверка безопасности платежного приложения

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

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

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

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

Подраздел 6.7. Кейс седьмой: спор о соответствии интерфейса требованиям задания

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

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

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

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

Подраздел 6.8. Кейс восьмой: проверка совместимости программного обеспечения

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

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

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

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

Подраздел 6.9. Кейс девятый: оценка надежности системы резервного копирования

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

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

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

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

Подраздел 6.10. Кейс десятый: комплексная экспертиза соответствия программного обеспечения техническому заданию

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

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

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

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

Раздел 7. Документирование результатов и оформление выводов

Подраздел 7.1. Структура экспертного заключения

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

Экспертиза соответствия ПО техническому заданию предъявляет к заключению особые требования. Поскольку предметом исследования является соответствие продукта заданию, заключение должно содержать четкое указание на то, какие требования задания проверялись и какие результаты получены. Недостаточно ограничиться общим выводом «соответствует» или «не соответствует». Нужно показать, какие именно требования выполнены, какие не выполнены, и на каком основании сделан вывод. Это делает заключение проверяемым и повышает его доказательственную силу.

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

Подраздел 7.2. Требования к описанию методов и результатов

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

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

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

Подраздел 7.3. Формулирование выводов

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

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

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

Раздел 8. Организационные и методические аспекты взаимодействия с заказчиком

Подраздел 8.1. Порядок постановки вопросов перед экспертом

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

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

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

Подраздел 8.2. Взаимодействие с заказчиком в ходе экспертизы

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

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

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

Подраздел 8.3. Конфиденциальность и защита информации

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

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

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

Раздел 9. Типичные ошибки и ограничения экспертизы соответствия ПО техническому заданию

Подраздел 9.1. Ошибки, связанные с истолкованием задания

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

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

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

Подраздел 9.2. Ошибки, связанные с методами testing

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

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

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

Подраздел 9.3. Ограничения экспертизы

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

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

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

Раздел 10. Вопросы, которые часто возникают при экспертизе соответствия ПО техническому заданию

Подраздел 10.1. Можно ли провести экспертизу без доступа к исходному коду

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

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

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

Подраздел 10.2. Как быть, если задание содержит противоречия

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

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

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

Подраздел 10.3. Что делать, если продукт изменяется в ходе экспертизы

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

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

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

Раздел 11. Значение экспертизы соответствия ПО техническому заданию для разрешения споров

Подраздел 11.1. Роль экспертизы в доказывании

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

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

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

Подраздел 11.2. Использование результатов экспертизы в переговорах

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

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

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

Подраздел 11.3. Пределы использования экспертного заключения

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

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

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

Раздел 12. Заключительные положения

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

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

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

Приглашаем вас в наш офис в центре Москвы на метро Павелецкая для обсуждения вопросов, связанных с экспертизой соответствия ПО техническому заданию. Мы готовы провести предварительную консультацию, определить цели и объем исследования, а также ответить на ваши вопросы. Вы можете связаться с нами по телефонам 8(495) 666-5-666, 8-(800) 555-04-53 или по электронной почте info@fse.ms. Союз «Федерация судебных экспертов».