Теоретические основания экспертизы пользовательских сценариев как части экспертизы программного продукта на соответствие ТЗ 📚
Экспертиза программного продукта на соответствие ТЗ представляет собой комплексную процедуру оценивания, в рамках которой устанавливается степень соответствия реализованных характеристик программного продукта требованиям, зафиксированным в техническом задании. Одним из ключевых, но при этом наименее формализованных направлений такой экспертизы выступает анализ пользовательских сценариев. Пользовательский сценарий в широком смысле понимается как последовательность действий пользователя, направленная на достижение определённой цели при взаимодействии с программным продуктом, вместе с ожидаемой реакцией системы на каждое из этих действий. Именно сценарии связывают декларативные требования технического задания с фактическим поведением программного продукта в условиях его эксплуатации.
Теоретическая основа экспертизы пользовательских сценариев опирается на несколько взаимосвязанных положений. Первое из них состоит в том, что техническое задание, как правило, формулирует требования в терминах свойств и функций, тогда как пользователь воспринимает программный продукт в терминах задач и последовательностей их решения. Разрыв между этими двумя способами описания создаёт зону неопределённости, в которой и возникает большинство спорных ситуаций при приёмке. Экспертиза пользовательских сценариев призвана сократить этот разрыв, обеспечивая переводимость функциональных требований в проверяемые последовательности взаимодействия.
Второе положение связано с различением сценария как проектного артефакта и сценария как предмета экспертного оценивания. В проектной практике сценарии нередко создаются заранее и служат инструментом проектирования. В экспертной практике сценарии могут как извлекаться из технического задания, так и реконструироваться на основе анализа самого программного продукта. Экспертиза программного продукта на соответствие ТЗ в этом отношении требует, чтобы предметом сопоставления были именно те сценарии, которые предусмотрены или подразумеваются техническим заданием, а не произвольно выбранные разработчиком или экспертом примеры использования.
Третье положение касается уровней детализации сценариев. Сценарий может быть описан на уровне цели, на уровне укрупнённых шагов, на уровне отдельных операций или на уровне элементарных взаимодействий с элементами интерфейса. Соответствие техническому заданию может оцениваться по-разному в зависимости от выбранного уровня. Если техническое задание формулирует требование в общем виде, экспертиза не должна искусственно повышать детализацию и предъявлять к продукту требования, которых в задании не было. Напротив, если задание содержит детальные предписания, экспертиза обязана проверить их исполнение на соответствующем уровне. Таким образом, ключевым теоретическим принципом является согласование уровня детализации экспертного анализа с уровнем детализации требований.
Четвёртое положение связано с разграничением полноты, корректности и непротиворечивости сценариев. Полнота означает, что для всех целей, предусмотренных техническим заданием, существует хотя бы один сценарий их достижения. Корректность означает, что каждый шаг сценария приводит к ожидаемому результату и не нарушает ограничений, установленных заданием. Непротиворечивость означает, что различные сценарии не требуют взаимоисключающего поведения системы в одинаковых условиях. Эти три характеристики образуют базовую систему координат, в которой разворачивается экспертиза пользовательских сценариев.
Пятое положение касается роли контекста использования. Один и тот же программный продукт может эксплуатироваться в разных условиях, разными категориями пользователей, с разными данными и разными ограничениями. Техническое задание может явно оговаривать эти контексты или подразумевать их. Экспертиза пользовательских сценариев должна учитывать контексты, релевантные техническому заданию, и не подменять их контекстами, которые в задании не рассматривались. В этом смысле экспертиза всегда относительна: она оценивает не сценарии вообще, а сценарии в их отношении к конкретному техническому заданию.
Наконец, шестое положение состоит в том, что пользовательский сценарий является одновременно единицей анализа и единицей свидетельства. Как единица анализа он позволяет структурировать экспертное исследование, разбивая его на обозримые и проверяемые фрагменты. Как единица свидетельства он позволяет фиксировать результаты проверки в форме, которая может быть предъявлена заинтересованным сторонам. Совокупность этих положений образует теоретический фундамент, на котором строятся последующие части, посвящённые месту сценариев в техническом задании, методологии их выявления, критериям соответствия, инструментальным методам, классификации дефектов и оформлению результатов.
Место пользовательских сценариев в структуре технического задания и требованиях к программному продукту 💼
Техническое задание представляет собой документ, в котором фиксируются требования к программному продукту, условия его разработки, порядок приёмки и иные существенные для сторон положения. Пользовательские сценарии могут присутствовать в техническом задании в явной форме, в форме косвенных указаний или не присутствовать вовсе. От того, в какой форме сценарии отражены в задании, напрямую зависит характер и глубина экспертизы программного продукта на соответствие ТЗ. В настоящей части рассматривается структура технического задания применительно к сценариям и определяются типовые способы их закрепления в требованиях.
В явной форме пользовательские сценарии чаще всего закрепляются в разделах, описывающих функциональные требования, бизнес-процессы, варианты использования или порядок работы пользователя. Такие разделы могут содержать перечни шагов, таблицы действий и ожидаемых реакций, текстовые описания потоков событий, диаграммы деятельности или последовательностей. Если техническое задание содержит подобные материалы, экспертиза получает готовую систему координат: каждый описанный сценарий может быть проверен на реализуемость, полноту и корректность. Однако даже в этом случае остаётся вопрос о том, являются ли перечисленные сценарии исчерпывающими и не подразумевает ли задание иных сценариев, не выписанных явно.
В косвенной форме сценарии присутствуют в техническом задании тогда, когда требования сформулированы в виде функций, правил обработки данных, ограничений или критериев качества, но без описания последовательности действий пользователя. Например, требование о том, что система должна обеспечивать формирование отчёта за заданный период, подразумевает сценарий, включающий выбор периода, запуск формирования, ожидание результата и получение отчёта. Экспертиза в таком случае вынуждена реконструировать сценарии из требований, и качество этой реконструкции становится отдельным предметом оценивания. Ошибка реконструкции может привести к предъявлению продукту требований, которых задание не содержало, либо к пропуску требований, которые задание содержало.
Отсутствие сценариев в техническом задании не означает отсутствия необходимости их экспертизы. Оно означает лишь, что экспертиза должна опираться на иные источники: цели создания продукта, описание назначения, перечни пользовательских ролей, а также на общие принципы, зафиксированные в задании. В таких условиях возрастает роль экспертного усмотрения и, соответственно, требования к обоснованности выводов. Экспертиза программного продукта на соответствие ТЗ в подобной ситуации должна особенно тщательно фиксировать, какие сценарии были признаны подразумеваемыми, на каком основании и какие последствия это влечёт для итоговой оценки.
Структурно пользовательские сценарии в техническом задании могут быть привязаны к различным элементам. Они могут быть привязаны к ролям пользователей, к функциям системы, к объектам предметной области, к бизнес-процессам, к режимам работы или к этапам жизненного цикла обработки данных. Каждая из этих привязок задаёт свой способ группировки сценариев и, соответственно, свой порядок экспертного анализа. При экспертизе важно сохранять ту систему группировки, которая принята в техническом задании, поскольку произвольная перегруппировка может исказить представление о полноте требований.
Отдельного внимания заслуживает вопрос о соотношении пользовательских сценариев и нефункциональных требований. Производительность, надёжность, безопасность, удобство использования и другие качества программного продукта проявляются именно в сценариях. Требование о времени отклика не имеет смысла вне сценария, в котором пользователь выполняет определённую операцию. Требование о сохранности данных также проверяется через сценарии, включающие возникновение сбоев и восстановление. Поэтому экспертиза сценариев не может ограничиваться функциональной стороной: она должна учитывать, какие нефункциональные требования технического задания проверяются в рамках каждого сценария и каким образом.
Наконец, важным является вопрос об изменяемости технического задания. В ходе разработки задание может уточняться, дополняться или пересматриваться. Пользовательские сценарии, зафиксированные в первоначальной редакции, могут перестать соответствовать актуальной редакции. Экспертиза должна установить, какая редакция задания является основанием для оценки, и в какой мере изменения затронули сценарии. Игнорирование этого вопроса приводит к спорам о том, какие требования следует считать обязательными. Таким образом, место сценариев в структуре технического задания определяется не только их текстуальным положением, но и их отношением к редакциям документа, к системе требований и к контексту их применения.
Методология выявления и формализации пользовательских сценариев при проведении экспертизы программного продукта на соответствие ТЗ 🔬
Методология выявления и формализации пользовательских сценариев образует ядро практической части экспертизы. От того, насколько полно и точно будут выявлены сценарии, зависит содержательность всех последующих оценок. В настоящей части рассматриваются источники сведений о сценариях, процедуры их извлечения, способы формализации и правила фиксации результатов выявления. Экспертиза программного продукта на соответствие ТЗ требует, чтобы выявление сценариев было воспроизводимым и обоснованным, а не интуитивным.
Первым источником сведений о сценариях является техническое задание. Из него извлекаются явно описанные сценарии, а также требования, из которых сценарии могут быть выведены. Извлечение явных сценариев сводится к их идентификации, наименованию и приведению к единой форме. Выведение неявных сценариев требует более сложной работы: необходимо установить, какая пользовательская цель стоит за требованием, какие шаги необходимы для её достижения, какие условия должны быть выполнены и какие результаты должны быть получены. Результатом этого этапа является перечень сценариев с указанием источника каждого из них.
Вторым источником является сам программный продукт. Анализ интерфейса, документации, сообщений системы, доступных действий и реакций позволяет реконструировать сценарии, фактически поддерживаемые продуктом. Сопоставление сценариев, выведенных из технического задания, со сценариями, поддерживаемыми продуктом, даёт первичную картину соответствия. При этом важно различать сценарии, которые продукт поддерживает, и сценарии, которые он декларирует. Наличие элемента интерфейса не всегда означает, что соответствующий сценарий реализован полностью и корректно.
Третьим источником являются пользовательские роли и категории пользователей, указанные в техническом задании или вытекающие из назначения продукта. Каждая роль задаёт свой набор целей и, соответственно, свой набор сценариев. Выявление сценариев по ролям позволяет обеспечить полноту и избежать ситуаций, когда анализируются только сценарии одной категории пользователей. Если техническое задание не содержит перечня ролей, экспертиза должна зафиксировать это обстоятельство и указать, на каком основании были определены роли, принятые для анализа.
Четвёртым источником являются данные и объекты предметной области. Сценарии часто различаются в зависимости от типа обрабатываемых данных, их объёма, состояния и происхождения. Выявление сценариев по данным позволяет охватить граничные и особые случаи, которые неочевидны при анализе только пользовательских целей. К таким случаям относятся пустые наборы данных, большие объёмы, противоречивые значения, отсутствующие обязательные элементы и иные ситуации, требующие особого поведения системы.
Формализация выявленных сценариев предполагает приведение их к единой структуре. Такая структура обычно включает наименование сценария, цель, действующее лицо, предусловия, основной поток шагов, альтернативные потоки, постусловия и ожидаемые результаты. Единообразие структуры обеспечивает сопоставимость сценариев между собой и возможность их последующей проверки. Формализация не должна приводить к потере существенных деталей: если техническое задание содержит специфические указания, они должны быть отражены в соответствующих элементах структуры.
Особым вопросом является установление границ сценария. Один и тот же процесс может быть описан как один сценарий или как несколько взаимосвязанных сценариев. Чрезмерное укрупнение затрудняет проверку, чрезмерное дробление создаёт избыточность и усложняет оценку полноты. Методологически целесообразно выбирать такой уровень дробления, при котором каждый сценарий имеет самостоятельную пользовательскую цель и самостоятельный ожидаемый результат. Если цель не может быть достигнута в рамках сценария без достижения промежуточной цели, последняя может рассматриваться как отдельный сценарий или как шаг основного.
Завершающим этапом методологии является фиксация результатов выявления и формализации. Фиксируются перечень сценариев, источники их происхождения, принятые допущения, спорные и неоднозначные случаи, а также сценарии, которые были признаны выходящими за пределы технического задания. Такая фиксация обеспечивает прозрачность экспертизы и позволяет впоследствии проверить обоснованность выводов. Совокупность описанных процедур образует методологическую основу, на которой строятся критерии соответствия, инструментальные методы и классификация дефектов, рассматриваемые в следующих частях.
Критерии и показатели соответствия пользовательских сценариев требованиям технического задания 💻
Оценка соответствия пользовательских сценариев требованиям технического задания требует системы критериев, которые позволяют перейти от описаний к выводам. В настоящей части рассматриваются основные критерии, их содержание, способы применения и ограничения. Экспертиза программного продукта на соответствие ТЗ опирается на эти критерии как на инструмент, обеспечивающий единообразие и обоснованность оценок.
Первым критерием является наличие сценария. Он отвечает на вопрос, существует ли в программном продукте возможность достижения цели, предусмотренной техническим заданием. Наличие сценария устанавливается путём проверки того, что все необходимые для достижения цели действия доступны пользователю и приводят к требуемому результату. Отсутствие сценария может быть полным, когда цель недостижима, или частичным, когда достижима лишь часть результата. Показателем наличия служит факт достижения цели при выполнении предусмотренных действий.
Вторым критерием является полнота сценария. Он отвечает на вопрос, охватывает ли сценарий все существенные аспекты, предусмотренные техническим заданием. Полнота оценивается по составу шагов, по охвату альтернативных потоков, по учёту граничных условий и по обработке ошибок. Показателями полноты могут служить доля реализованных шагов от предусмотренных заданием, доля обработанных альтернативных ситуаций, наличие реакций на типовые и особые условия. Полнота не означает избыточности: сценарий, содержащий лишние шаги, не предусмотренные заданием, не становится от этого более полным.
Третьим критерием является корректность сценария. Он отвечает на вопрос, приводит ли выполнение шагов сценария к результатам, соответствующим техническому заданию. Корректность оценивается по каждому шагу и по сценарию в целом. Показателями корректности служат соответствие результатов ожидаемым, отсутствие недопустимых побочных эффектов, соблюдение ограничений и правил, установленных заданием. Корректность может нарушаться как при неверном результате, так и при верном результате, полученном недопустимым способом.
Четвёртым критерием является непротиворечивость сценариев. Он отвечает на вопрос, совместимы ли различные сценарии между собой. Противоречие возникает тогда, когда выполнение одного сценария делает невозможным или затруднительным выполнение другого, либо когда в одинаковых условиях система ведёт себя по-разному в зависимости от того, каким сценарием воспользовался пользователь. Показателями непротиворечивости служат отсутствие взаимоисключающих требований к состоянию системы и отсутствие конфликтов между сценариями при их совместном выполнении.
Пятым критерием является устойчивость сценария к отклонениям. Он отвечает на вопрос, сохраняет ли сценарий работоспособность при отклонении условий от типовых. Отклонения могут касаться данных, последовательности действий, состояния внешней среды, поведения самого пользователя. Показателями устойчивости служат наличие обработки ошибочных ситуаций, сохранение целостности данных, возможность продолжения работы или корректного завершения. Устойчивость тесно связана с полнотой, но не совпадает с ней: сценарий может быть полным по составу шагов и при этом неустойчивым к отклонениям.
Шестым критерием является проверяемость сценария. Он отвечает на вопрос, может ли результат выполнения сценария быть установлен объективно. Если результат формулируется в терминах, допускающих неоднозначное толкование, проверяемость снижается. Показателями проверяемости служат наличие наблюдаемых признаков результата, возможность их фиксации, однозначность соответствия между действиями и результатами. Проверяемость важна не только для экспертизы, но и для последующей приёмки.
Седьмым критерием является соответствие сценария уровню детализации технического задания. Как отмечалось ранее, требования задания могут быть сформулированы с разной степенью конкретности. Оценка не должна предъявлять к продукту требований более высокого уровня детализации, чем тот, который задан. Показателем соответствия служит отсутствие в выводах экспертизы положений, не выводимых из задания. Этот критерий носит ограничительный характер и защищает от необоснованного расширения предмета оценки.
Перечисленные критерии применяются совместно. Ни один из них в отдельности не даёт достаточного основания для итогового вывода. Наличие сценария без корректности не означает соответствия; корректность без полноты оставляет непроверенными существенные аспекты; полнота без непротиворечивости может привести к конфликтам. Совокупная оценка строится как последовательное применение критериев к каждому сценарию и последующее обобщение результатов по группам сценариев и по продукту в целом.
Инструментальные и документарные методы проверки пользовательских сценариев в рамках экспертизы 🛠️
Проверка пользовательских сценариев осуществляется с помощью методов, которые делятся на документарные и инструментальные. Документарные методы опираются на анализ документов, инструментальные — на непосредственное взаимодействие с программным продуктом и на сбор данных о его поведении. В настоящей части рассматриваются обе группы методов, их возможности, ограничения и порядок применения. Экспертиза программного продукта на соответствие ТЗ использует сочетание этих методов, поскольку каждый из них в отдельности даёт неполную картину.
Документарные методы включают анализ технического задания, анализ проектной документации, анализ пользовательской документации и сопоставление документов между собой. Анализ технического задания позволяет установить требования, подлежащие проверке, и выявить сценарии, подлежащие оценке. Анализ проектной документации позволяет понять, каким образом разработчик предполагал реализовать требования, и обнаружить расхождения между замыслом и заданием. Анализ пользовательской документации позволяет установить, какие сценарии предлагаются пользователю и насколько они соответствуют заданию. Сопоставление документов выявляет противоречия, пробелы и расхождения, которые затем проверяются инструментально.
Инструментальные методы включают ручное тестирование по сценариям, автоматизированное выполнение сценариев, протоколирование действий и результатов, а также анализ журналов работы системы. Ручное тестирование позволяет эксперту непосредственно убедиться в поведении продукта, оценить не только результат, но и способ его достижения. Автоматизированное выполнение обеспечивает воспроизводимость и позволяет многократно повторять проверку при изменении условий. Протоколирование фиксирует ход проверки и служит доказательной базой. Анализ журналов позволяет выявить скрытые эффекты, не наблюдаемые непосредственно в интерфейсе.
Особое значение имеет метод проверки по граничным и особым условиям. Он предполагает выполнение сценария при значениях данных и параметров, близких к границам допустимых диапазонов, а также в ситуациях, которые техническое задание относит к особым. К таким ситуациям относятся отсутствие данных, их избыток, противоречивость, нарушение форматов, прерывание операции, одновременное выполнение конкурирующих действий. Проверка по граничным условиям позволяет обнаружить дефекты, которые не проявляются при типовом выполнении.
Метод сравнительной проверки состоит в выполнении одного и того же сценария различными способами и сопоставлении результатов. Если различные пути достижения одной цели приводят к разным результатам, это может свидетельствовать о внутренней противоречивости реализации или о неполноте технического задания. Сравнительная проверка также применяется при оценке согласованности различных сценариев между собой.
Метод обратной проверки состоит в движении от наблюдаемого результата к действиям, которые к нему привели. Он применяется в тех случаях, когда прямой сценарий не описан в задании, но результат, предусмотренный заданием, наблюдается. Обратная проверка позволяет установить, каким образом результат достигается и соответствует ли этот способ требованиям задания. Метод полезен при анализе неявных сценариев и при оценке сценариев, реконструированных экспертом.
Метод документирования расхождений сопровождает все перечисленные методы. Каждое расхождение фиксируется с указанием сценария, шага, условия, ожидаемого и фактического результата, а также источника требования, которому противоречит фактический результат. Такая фиксация обеспечивает возможность последующей проверки и обсуждения. Без документирования расхождений экспертиза теряет доказательную силу.
Выбор методов определяется характером сценария, доступностью продукта, наличием документации и ограничениями по времени. Не все методы применимы ко всем сценариям. Например, автоматизированное выполнение может быть затруднено для сценариев, требующих сложного взаимодействия с внешними системами или участия человека. В таких случаях применяются ручные методы с тщательным протоколированием. Сочетание методов должно обеспечивать достаточную полноту проверки при разумных затратах.
Ограничения методов также должны учитываться. Документарные методы зависят от полноты и достоверности документов. Инструментальные методы зависят от доступности продукта и от возможности воспроизведения условий. Ни один метод не гарантирует выявления всех дефектов. Поэтому в выводах экспертизы следует указывать, какие методы применялись, какие ограничения имели место и как это влияет на достоверность результатов. Совокупность документарных и инструментальных методов образует практический аппарат, применяемый в рамках экспертизы пользовательских сценариев.
Типовые дефекты пользовательских сценариев и их классификация по результатам экспертизы 💼
Дефекты пользовательских сценариев представляют собой отклонения от требований технического задания, выявляемые в ходе экспертизы. Систематизация дефектов позволяет упорядочить результаты проверки, выявить их причины и определить последствия. В настоящей части рассматриваются типовые дефекты, их классификация и способы описания. Экспертиза программного продукта на соответствие ТЗ нуждается в такой классификации, поскольку она обеспечивает единообразие выводов и облегчает их восприятие заинтересованными сторонами.
Первая группа дефектов связана с отсутствием сценария. Сценарий может отсутствовать полностью, когда предусмотренная заданием цель недостижима. Он может отсутствовать частично, когда достижима лишь часть результата или когда достижение возможно только при условиях, не предусмотренных заданием. Отсутствие сценария может быть явным, обнаруживаемым при непосредственной проверке, или скрытым, проявляющимся лишь при определённых сочетаниях условий. Скрытые формы особенно опасны, поскольку создают иллюзию соответствия.
Вторая группа дефектов связана с неполнотой сценария. Сценарий может не охватывать все шаги, предусмотренные заданием, не учитывать альтернативные потоки, не обрабатывать ошибки, не учитывать граничные условия. Неполнота может проявляться в том, что сценарий работает при типовых условиях и отказывает при отклонениях. Неполнота может также проявляться в отсутствии промежуточных результатов, предусмотренных заданием, или в отсутствии возможности вернуться к предыдущему состоянию.
Третья группа дефектов связана с некорректностью сценария. Сценарий может приводить к результату, не соответствующему заданию, или к результату, соответствующему заданию, но полученному недопустимым способом. Некорректность может проявляться в неверных значениях, в нарушении ограничений, в побочных эффектах, в повреждении данных, в нарушении последовательности операций. Некорректность может быть постоянной или зависеть от условий выполнения.
Четвёртая группа дефектов связана с противоречивостью сценариев. Различные сценарии могут предъявлять взаимоисключающие требования к состоянию системы или к порядку действий. Противоречивость может проявляться в том, что выполнение одного сценария блокирует выполнение другого, или в том, что одинаковые действия в одинаковых условиях приводят к разным результатам в зависимости от предыстории. Противоречивость может быть следствием как ошибок реализации, так и неполноты технического задания.
Пятая группа дефектов связана с недостаточной устойчивостью сценария. Сценарий может быть корректным при типовых условиях и разрушаться при отклонениях. Неустойчивость проявляется в отказах, в потере данных, в невозможности продолжения работы, в появлении неопределённых состояний. Неустойчивость может быть вызвана отсутствием обработки ошибок, недостаточной проверкой входных данных, неучётом конкурирующих действий.
Шестая группа дефектов связана с недостаточной проверяемостью сценария. Результат сценария может быть сформулирован неоднозначно, не иметь наблюдаемых признаков, не допускать объективной фиксации. Непроверяемость затрудняет не только экспертизу, но и последующую приёмку, поскольку стороны не могут прийти к согласию относительно того, достигнут результат или нет. Непроверяемость может быть следствием как формулировок задания, так и особенностей реализации.
Седьмая группа дефектов связана с несоответствием уровня детализации. Сценарий может быть описан или реализован на уровне, не соответствующем уровню требований задания. Если задание требует детальной проработки, а реализация ограничивается укрупнёнными действиями, возникает несоответствие. Если задание формулирует требование в общем виде, а экспертиза предъявляет детальные требования, возникает необоснованное расширение предмета оценки. Оба случая требуют различения и соответствующей квалификации.
Классификация дефектов может проводиться по различным основаниям: по источнику возникновения, по последствиям, по степени критичности, по возможности устранения. По источнику различают дефекты задания, дефекты проектирования, дефекты реализации и дефекты документирования. По последствиям различают дефекты, блокирующие достижение цели, снижающие качество результата, создающие неудобства и не влияющие на результат. По степени критичности различают критические, значительные и незначительные. По возможности устранения различают устранимые и неустранимые в рамках имеющихся ограничений.
Описание каждого дефекта должно включать сценарий, шаг, условие, ожидаемый результат, фактический результат, источник требования и квалификацию дефекта. Такое описание обеспечивает возможность проверки и последующего анализа. Совокупность описанных дефектов образует основу для итоговых выводов экспертизы и для рекомендаций, если их представление предусмотрено порядком проведения экспертизы.
Оформление результатов экспертизы пользовательских сценариев и их интерпретация для целей соответствия ТЗ 📄
Оформление результатов экспертизы пользовательских сценариев представляет собой заключительный этап, на котором разрозненные наблюдения и оценки преобразуются в документ, пригодный для использования заинтересованными сторонами. В настоящей части рассматриваются структура итогового документа, принципы интерпретации результатов и правила формулирования выводов. Экспертиза программного продукта на соответствие ТЗ завершается документом, в котором должны быть ясно разделены установленные факты, их оценка и итоговые выводы.
Структура итогового документа включает несколько обязательных элементов.
- Первый элемент — предмет экспертизы, в котором указывается, какие сценарии и какие требования технического задания были подвергнуты оценке.
- Второй элемент — методы, в котором перечисляются применённые документарные и инструментальные методы и указываются ограничения их применения.
- Третий элемент — перечень проверенных сценариев с указанием источника каждого сценария и принятых допущений.
- Четвёртый элемент — результаты проверки по каждому сценарию с описанием выявленных расхождений.
- Пятый элемент — обобщённая оценка соответствия.
- Шестой элемент — выводы.
Разделение фактов и оценок является принципиальным требованием. Факты описывают наблюдаемое поведение продукта и его отношение к требованиям задания. Оценки квалифицируют это отношение как соответствие, несоответствие или неопределённость. Смешение фактов и оценок затрудняет проверку выводов и создаёт почву для споров. Каждый вывод должен опираться на зафиксированные факты и на явно указанные критерии.
Интерпретация результатов требует учёта нескольких обстоятельств.
- Необходимо учитывать полноту проверки: если проверены не все сценарии, выводы не могут распространяться на непроверенные.
- Необходимо учитывать ограничения методов: если проверка проводилась в условиях, отличных от эксплуатационных, это должно быть отражено.
- Необходимо учитывать редакцию технического задания, по которой проводилась оценка.
- Необходимо учитывать принятые допущения о неявных сценариях и о степени детализации.
Формулирование выводов должно быть определённым и не допускать расширительного толкования. Выводы могут касаться отдельных сценариев, групп сценариев или продукта в целом. Вывод по отдельному сценарию указывает, соответствует ли сценарий требованиям задания, и если нет, то в чём состоит несоответствие. Вывод по группе сценариев обобщает результаты по однородным сценариям. Вывод по продукту в целом формулируется с учётом всех проверенных сценариев и всех выявленных дефектов.
Особого внимания требует интерпретация неопределённых случаев. Если требование задания допускает несколько толкований, а продукт реализует одно из них, вывод должен указывать на неоднозначность и на то, какое толкование было принято. Если сценарий не удалось проверить полностью, вывод должен указывать на непроверенную часть и на причины. Если дефект носит пограничный характер, вывод должен содержать обоснование его квалификации.
Результаты экспертизы могут использоваться для различных целей: для приёмки продукта, для планирования доработок, для разрешения споров, для подтверждения качества. В зависимости от цели меняются акценты, но структура документа и требования к обоснованности сохраняются. Документ должен быть понятен как специалистам, так и неспециалистам, поскольку среди заинтересованных сторон могут быть представители заказчика, разработчика и иных участников.
Интерпретация результатов не должна подменяться рекомендациями. Если рекомендации предусмотрены порядком проведения экспертизы, они оформляются отдельно и не влияют на итоговую оценку соответствия. Оценка отвечает на вопрос, соответствует ли продукт заданию, а рекомендации — на вопрос, каким образом можно устранить выявленные несоответствия. Смешение этих двух аспектов приводит к размыванию выводов и к затруднениям при принятия решений.
Заключение ✅
Проведённое исследование было посвящено экспертизе пользовательских сценариев как одному из направлений экспертизы программного продукта на соответствие ТЗ. В рамках статьи последовательно рассмотрены теоретические основания этого направления, место сценариев в структуре технического задания, методология их выявления и формализации, критерии и показатели соответствия, инструментальные и документарные методы проверки, классификация типовых дефектов, а также вопросы оформления и интерпретации результатов.
Теоретическая часть показала, что пользовательский сценарий является связующим звеном между декларативными требованиями технического задания и фактическим поведением программного продукта. Именно через сценарии функциональные и нефункциональные требования обретают проверяемую форму. Разрыв между способом описания требований в задании и способом восприятия продукта пользователем создаёт зону неопределённости, которая может быть сокращена только целенаправленной экспертной работой. При этом экспертиза программного продукта на соответствие ТЗ должна сохранять относительность оценки: она оценивает сценарии не вообще, а в их отношении к конкретному техническому заданию и к его действующей редакции.
Анализ места сценариев в структуре технического задания показал, что они могут присутствовать в явной, косвенной или неявной форме. Каждая форма требует своего подхода: явные сценарии подлежат непосредственной проверке, косвенные — реконструкции, неявные — обоснованному выведению из целей, ролей и назначения продукта. Во всех случаях эксперт обязан фиксировать источник сценария и принятые допущения, поскольку от этого зависит обоснованность итоговых выводов. Особое внимание уделено согласованию уровня детализации анализа с уровнем детализации требований, что защищает экспертизу от необоснованного расширения предмета оценки.
Методологическая часть исследования показала, что выявление и формализация сценариев должны быть воспроизводимыми и прозрачными. Источниками сведений о сценариях выступают техническое задание, сам программный продукт, пользовательские роли и данные предметной области. Формализация сценариев к единой структуре обеспечивает их сопоставимость и проверяемость. Установление границ сценария требует методической осторожности: чрезмерное укрупнение затрудняет проверку, чрезмерное дробление создаёт избыточность. Выбор уровня дробления должен опираться на наличие самостоятельной пользовательской цели и самостоятельного ожидаемого результата.
Система критериев, рассмотренная в статье, включает наличие, полноту, корректность, непротиворечивость, устойчивость, проверяемость и соответствие уровню детализации. Ни один из этих критериев не является достаточным в отдельности; только их совместное применение даёт основание для итогового вывода. Такое построение системы критериев позволяет упорядочить экспертное суждение и снизить влияние субъективных факторов.
Рассмотрение документарных и инструментальных методов подтвердило необходимость их сочетания. Документарные методы обеспечивают понимание требований и замысла, инструментальные — непосредственную проверку поведения продукта. Методы граничных условий, сравнительной и обратной проверки расширяют возможности выявления дефектов, которые не обнаруживаются при типовом выполнении сценариев. Документирование расхождений на всех этапах проверки обеспечивает доказательную силу результатов и возможность их последующего обсуждения.
Классификация типовых дефектов пользовательских сценариев позволила систематизировать отклонения по группам: отсутствие сценария, неполнота, некорректность, противоречивость, недостаточная устойчивость, недостаточная проверяемость и несоответствие уровня детализации. Дополнительные основания классификации — источник возникновения, последствия, степень критичности и возможность устранения — дают возможность квалифицировать дефекты с учётом целей экспертизы. Описание каждого дефекта с указанием сценария, шага, условия, ожидаемого и фактического результата, источника требования и квалификации обеспечивает проверяемость выводов.
Заключительная часть исследования показала, что оформление результатов должно строго разделять факты, оценки и выводы. Итоговый документ должен содержать предмет экспертизы, применённые методы и их ограничения, перечень проверенных сценариев с источниками и допущениями, результаты проверки, обобщённую оценку и выводы. Интерпретация результатов требует учёта полноты проверки, ограничений методов, редакции технического задания и принятых допущений. Выводы должны быть определёнными и не допускать расширительного толкования, а неопределённые случаи должны сопровождаться указанием на причины неопределённости.
📌 Таким образом, экспертиза пользовательских сценариев представляет собой самостоятельное направление экспертизы программного продукта на соответствие ТЗ, обладающее собственным теоретическим фундаментом, методологическим аппаратом, системой критериев и правилами оформления результатов. Дальнейшее развитие этого направления связано с уточнением способов выявления неявных сценариев, совершенствованием методов проверки в условиях ограниченного доступа к продукту и повышением однозначности формулировок технических заданий. Однако и в существующем виде рассмотренный подход позволяет получать обоснованные, воспроизводимые и доказательные оценки соответствия пользовательских сценариев требованиям технического задания.
Задавайте любые вопросы