В русском языке осталась небольшая область, где требуется его доведение до современных реалий. Это касается западных практик в области управления людьми и коллективами. Они слабо изучались советской наукой, при этом в 90-х началось их ускоренное внедрение людьми, которые совсем недавно считали их идеологически неверными. Так было с экономикой и в более специфических областях, например, касающихся производства программного обеспечения.
Писать отменный программный код у нас умели всегда. Но бизнес в сфере ПО шире простого наемного программирования — это торговля знаниями. А раз так, то требуется производство и его организация. Здесь ключевую роль играют системы управления сбором требований, где производственный процесс приходится выстраивать, опираясь на западный опыт.
Далее в статье разбираются типичные ошибки заимствования на примерах из перевода книги Карла И. Вигерса «Разработка требований к программному обеспечению». В конце обсуждаемый материал обобщается с помощью V-модели жизненного цикла проектных требований к ПО.
Безусловно любопытная книга Карла И. Вигерса «Разработка требований к программному обеспечению» (далее РТкПО) становится в российском информационном сообществе неким стандартом. Но использование положений из этой книги (заимствованных, оригинальных, переведенных) вне авторской концепции вызывает вопросы, в которых хотелось бы разобраться.
Это — иллюстрация развития требований по мере выполнения проекта сверху вниз, через три документа: «Документ об образе и границах проекта», «Документ о вариантах использования», «Спецификация требований к ПО». В 3-ем издании два первых документа представлены как «Документ концепции и границ» и «Документ пользовательских требований»
Для создания правильного документа надо, прежде всего, понимать его суть. Кажется, дело в разгадке таинственного «образ и границы проекта»: разгадал — и можно без ограничений и с большой выгодой пользоваться уже готовой практикой. К сожалению, это работает только с простыми технологиями, купленными у третьих лиц. Аспекты управления коллективами непосредственно связанны с особенностями чужой культуры, и там все совсем не просто. Культурные отличия есть видимая часть айсберга всей системы подсознательных этнических стереотипов поведения. А область бессознательного мы не контролируем совсем или контролируем только отчасти.
Тем не менее, не все так безнадежно. Нужно найти ассоциации их терминологии с нашей практикой. Разберем «Документ об образе и границах проекта». Границы проекта — project scope. Это следует переводить как «объем работ». Нет в словаре? Увы. Можно заглянуть в английский справочник: project scope — часть планирования проекта, включающая процесс определения, а затем и документирования конкретных целей проекта, результатов, задач, затрат и сроков. Есть конкретная процедура, почему бы ее не назвать «границами проекта»? В этом случае появятся проблемы с интеграцией собственного прошлого опыта: ведь мы и раньше занимались планированием и, в частности, определением объема работ.
Когда не получается перевод по словарю, надо поискать простую понятийную модель, иллюстрирующую применение спорного термина в близкой предметной области. Дальнейший перенос такой простой модели раскрытия на родную почву позволяет найти языковые соответствия. Модель «Ограничения треугольника» (triple constrains) — вводная в области управления проектами. 
В этой модели раскрывается связь терминов «время исполнения», «стоимость», «объем работ» (time, cost, scope), которые размещаются в виде равностороннего треугольника, подразумевая, что изменение одной стороны этого треугольника ведет к изменению всех.
Project Vision иногда переводят не как «образ проекта», а как «концепция проекта», но ясности это не добавляет. Project Vision Statement в справочнике определен как «идеалистический взгляд на желаемые бизнес-результаты, которые будут получены при успешном завершении проекта». Мы обычно используем термин «задачи проекта» и формулируем эти задачи с долей отечественного пессимизма. Если назовем «образом проекта», вряд ли это поможет проявиться западному оптимизму на родной почве. Итого, первый документ можно назвать «Цели проекта и объем работ”. И ничего загадочного.
Есть мнение, что подобные термины нужно не переводить, а использовать в проекте английский язык. Это работает лишь отчасти, сильно ограничивая круг людей, которые разбираются в вопросах на экспертном уровне. Базовых языковых навыков недостаточно там, где технологические вопросы касаются этно-культурных отличий.
Вот характерный пример из РТкПО: «Требования следует излагать последовательно, например, “система будет…” или “пользователь будет…”, затем — активный глагол, а после — наблюдаемый результат… Вы можете использовать “должно” как синоним “будет”, но избегайте “следовало бы”, “может”, “можно было бы” и аналогичных слов, из которых неясно, необходимо ли действие».
Можно подумать, что это готовое руководство к действию. На самом деле, этот перевод не помогает разобраться, а запутывает все еще больше. Более того, английский оригинал — не истина в последней инстанции, а выражение определенного взгляда на модальность английского языка. Взгляд закреплен в стандарте RFC2119**, который уточняет правила использования ключевых слов английского в области управления требованиями (e. g. must, shall, should, may). Например, по этому стандарту must означает, «что определение является абсолютным требованием спецификации». Однако автор встречал шаблоны документов с прямым запрещением использования must (объяснение такой позиции доступно в интернете***).
Следующий уровень детализации требований — «Документ о вариантах использования». В РТкПО, указано, что он определяет варианты использования, сценарии и таблицы «событие — отклик». Перевод «use cases» как «варианты использования» излишне упрощает взгляд на вещи (потому на практике закрепился англицизм юз-кейзы). Современное ПО должно иметь защиту от взлома и защиту от дурака, но считать это вариантом использования — насилие над русским языком. Для перевода предлагается «сценарии взаимодействий».
На самом деле модель «событие — отклик» нам известна. В высшей школе она изучается как «воздействие — флуктуация — > отклик». При одних и тех же воздействиях отклик системы может различаться из-за случайных флуктуаций. В пользовательском ПО это, как правило, различные ошибочные ситуации. Дополнительно на уровне концепции следует отличать воздействия окружающей среды от воздействий пользователя. Более или менее подходящее название для этого уровня требований — «Требования к системе» или уже «Требования к программному продукту», хотя терминология не устоялась, и встречаются очень разные варианты (например, в последнем издании используется название «Документ пользовательских требований», что автоматом исключает из рассмотрения встроенные системы).
Суть разработки требований этого уровня — создание детальной умозрительной модели ПО, функционирующей в идеализированном внешнем мире. Потому важный пункт — задание ограничений и принятие допущений (assumptions). «Цвет автомобиля может быть любым при условии, что он черный», — так Генри Форд переработал бизнес-требование к цветности автомобиля в допущение. Однако в другой раз для удовлетворения бизнес-требования к чистоте автомобиля оказалось необходимо изготовить неплоское обтекаемое стекло. Инженеры Форда сказали, что это технически невозможно. Форд нашел молодых изобретателей на стороне.
Нижний уровень представлен «Спецификацией требований к ПО», куда входят «ограничения», «внешний интерфейс», «атрибуты качества» и собственно «функциональные требования». Это — последний документ на рисунке, к сожалению, вопросы последующего тестирования не затрагиваются. Поэтому для формулирования определения РТкПО вынуждена привлечь понятие бизнес-требований: «функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований»
Со стороны тестирования определение построить проще: «Функциональные требования — требования, которые тестируются». Это надо понимать, как возможность проверки каждого функционального требования тестом в классическом понимании (c вердиктом — прошел или не прошел). Обратное, строго говоря, неверно: некоторые тесты могут существовать и сами по себе. Но наличие подобных тестов — показатель пропусков в работе над требованиями. Ведь тест проверяет какой-либо участок кода, который появился не сам по себе, а как результат исполнения некого функционального требования.
Современные зрелые процессы разработки ПО пытаются внести измерительную составляющую уже в ранние стадии изготовления программного продукта. Не вдаваясь в подробности — большей частью это всевозможные метрики покрытий. Один из показателей качества будущего продукта — процент покрытия тестами функциональных требований, который подсчитывается с помощью таблицы (матрицы) покрытия (traceability matrix). Включить в матрицу нефункциональное требование можно, но в дальнейшей работе оно будет помечено как нетестируемое, и, главное, тестировщики оценят его как бесполезное. Кажется, что полная «спецификация требований к ПО» со списком нефункциональных требований очень полезна программистам. И это, возможно было бы так, если бы после составления они туда заглядывали, хотя бы время от времени.
Абсолютное большинство нефункциональных требований можно записать функциональным образом. Перефразируя, практически любое нефункциональное требование к системе или программному продукту можно переработать в одно или несколько функциональных требований.
Атрибуты качества в РТкПО частично попадают в функциональные требования, что абсолютно верно. Однако ограничения и внешний интерфейс РТкПО определяет так: «другие нефункциональные требования описывают внешние взаимодействия между системой и внешним миром, ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта». У подсистем связи с внешним миром всегда есть интерфейс, который функционален и подлежит тестированию.
Могут ли ограничения быть функциональными требованиями? Определенно да, если записывать их в инвертированной форме как возможности. Например, продукт должен быть быстрее, чем у конкурентов (иначе он не нужен — очень жесткое ограничение). В первую очередь, речь идет о новизне принятых решений, задокументированных, в том числе, в виде требований. Но ясно, что у системы должен быть модуль измерения выявленных параметров этой быстроты, причем на ранней стадии.
Итак, «Функциональные спецификации» — устоявшееся название спецификаций нижнего уровня в виде форматированного документа или в виде базы данных под управлением специализированного ПО.
Что происходит с требованиями дальше? Кроме разработчиков(программистов) с требованиями будут работать инженеры по тестированию и инженеры QA(Quality Assurance). «Testing» можно перевести как «проверка», но заимствование «тестирование» видимо состоялось. Для перевода QA снова требуется модель раскрытия — здесь, какие принципы лежат в ее основе. Во-первых, «Fit for purpose» (продукт должен быть пригоден для намеченной цели), во-вторых, «right first time«(«с первого раза» — ошибки должны быть устранены) и в-третьих, проектная независимость. Это «Приемка», принципы лежат в основе широко известной военной приемки и легендарной госприемки.
Спецификации требований будут составлять основу дальнейших проектных документов. Как минимум, требования будут использованы при разработке пользовательской документации. Общепринято, что тестирование начинается планом тестирования и заканчивается отчетом тестирования — документами, непосредственно связанными со спецификациями. На рисунок в РТкПО можно посмотреть иначе — как на обобщенную модель процесса разработки ПО (или модель жизненного цикла ПО). В такой модели готовые документы — точки входа/выхода между фазами процесса.
В хронологическом порядке документы будут представлены так: бизнес-требования (как часть project scope), требования к системе(ПO), функциональные требования, план тестирования, отчет тестирования, пользовательская документация. Линия между двумя документами — фаза процесса. Модели часто рисуют в виде повторяющихся циклов или спирали, однако простая хронологическая ось более наглядна. Тогда первая и последняя фаза процесса обозначаются не отрезком, а лучом. В современных презентациях ось времени изгибают в середине фазы кодирования в виде буквы “V”, получая так называемую V-модель.
Прерывистые линии демонстрируют связи в обход хронологической оси, показывая возможность начать некоторые работы заблаговременно. Например, при сформулированных бизнес-требованиях можно уже что-то сказать о пользовательской документации продукта, а сформированные требования к системе дадут модель будущего ПО, качество которой уже можно начать оценивать.
Но основная функция этих линий — показать возможности скалируемости (упрощения) V-модели. Поддержка всех фаз и документов — всегда дорогое удовольствие, и очень частая причина проигрыша более мобильным конкурентам. Например, индивидуал работает так: бизнес-требования -> разработка (кодирование) -> пользовательская документация. Это верхняя прерывистая линия отреза. Аутсорсинговые компании, как правило, пропускают нижние фазы, не тратясь на функциональные спецификации и ограничиваясь тем или иным видом системных требований (например, сценариев взаимодействия). Для однотипных продуктов обычно есть стандарт предприятия, а с фазы кодирования выдается некий отчет внутреннего тестирования разработчиков, чтобы начать фазу «QA/приемки».
Основополагающая V-модель помогает уточнить зоны ответственности. Например, работник играет роль инженера по приемке(QA) или инженера по тестированию в зависимости от того, в какой фазе он работает. Неважно, закреплен ли он за конкретным проектом или отделом. То же самое относится к аналитику, проектировщику, разработчику — возможность выполнения всех этих ролей одним человеком не опровергает V-модель. Для инженера по приемке(QA) и аналитика основа — «Требования к системе», они работают с разрабатываемым ПО как с черным ящиком. Для вовлеченных в фазы проектирование, разработку и тестирование — это белый ящик, хоть и в разной мере.
В заключение стоит заметить, что V-модель— все-таки презентационная (в данном случае, иллюстрирующая проектную эволюцию требований). Это не прямое руководство к действию, реальные процессы разработки ПО сложнее. Но ее раскрывающей потенциал трудно преуменьшить.
* Карл И. Вигерс «Разработка требований к программному обеспечению».
** Key words for use in RFCs to Indicate Requirement Level (https://tools.ietf.org/html/rfc2119)
*** Must — Don’t use must because no one has defined how must is different from shall. Also, shall has held up in court, must has not. Granted, must does sounds stronger, right? I mean, if your boss tells you that you “must” do something, well you are going to do it. But, when writing requirements, keep things simple and just use shall (http://www.reqexperts.com/blog/2012/10/using-the-correct-terms-shall-will-should )
Источник
