Теоретические основания экспертизы частичной реализации технического задания 📚

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

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

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

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

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

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

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

Метрики и шкалы оценивания процента выполнения требований ТЗ 📋

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

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

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

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

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

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

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

Модели соотнесения реализованных функций с пунктами технического задания 📋

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

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

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

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

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

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

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

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

Методы выявления и квалификации частичной реализации в программном продукте 🔬

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обработка неполных, противоречивых и неоднозначных данных при оценке процента выполнения 💾

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

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

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

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

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

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

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

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

Оформление результатов экспертизы частичной реализации и процента выполнения ТЗ 📄

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

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

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

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

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

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

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

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

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

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

Заключение ✅

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

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

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

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

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

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